[ros-kernel] RE: [ros-cvs] CVS Update: reactos

Casper Hornstrup chorns at users.sourceforge.net
Fri Sep 10 12:49:32 CEST 2004


> -----Original Message-----
> From: ros-kernel-bounces at reactos.com 
> [mailto:ros-kernel-bounces at reactos.com] On Behalf Of Steven Edwards
> Sent: 10. september 2004 02:14
> To: chorns at users.sourceforge.net; ros-kernel at reactos.com
> Subject: [ros-kernel] RE: [ros-cvs] CVS Update: reactos
> Hi Casper,
> --- Casper Hornstrup <chorns at users.sourceforge.net> wrote:
> > I think we should keep tests that only test a single 
> component close 
> > to the component that is tested. See
> > http://www.reactos.com/en/content/view/full/543 for more 
> information.
> Ok cool. thats sorta the way Wine does it. Could we do it 
> like Wine where each test could be built as a standalone test 
> like kernel32_test.exe? Right now if I want to view the debug 
> output from your tests I have to do /DEBUGPORT=COM1 and 
> redirect to a pipe to view the results. I would like to be 
> able to do both console or DPRINT depending on the test mode. 
> It should not be to hard to redirect the Wine test output to 
> DPRINT when run in the mode you have planned for the CI system.
> I am still having trouble trying to figure out how to merge the
> kernel32 tests that I know pass in with your system. The 
> function params your system expects verse wine and the output 
> differ so when your _regtests.c gets generate the function 
> names and params dont match the way Wine autogenerates its testlist.c.
> Thanks
> Steven

We need to have the WINE tests return with success or failure
instead of just writing to standard output (preferably with an
explanation in case of failure).

Initially I wanted to run the tests in a VM, but this has proven
to be too difficult to be practical. The new method I'm researching
is using mock objects, commonly used in embedded development when
an emulator is uavailable or impractical. Of course, ReactOS has a
lot of C code so I'll call them mock functions. I want to push for
us using more Extreme Programming methods and for this to be practical,
we need to dramatically lower the time needed to implement and test
a change. The current method, which is to reboot ReactOS to test the
change, is very slow. We need to be able to run the tests in the build
environment. Currently, gdiplus is the only test for which you can
do this. IIRC the target is "make runtest".


More information about the Ros-kernel mailing list