RE: [ros-dev] Re: [ros-cvs] CVS Update: reactos

[Casper Hornstrup]

>   -----Original Message-----
>  From: ros-dev-bounces(a)reactos.com 
>  [mailto:[e-mail]] On Behalf Of Alex Ionescu
>  Sent: 24. oktober 2004 22:29
>  To: ReactOS Development List
>  Subject: Re: [ros-dev] Re: [ros-cvs] CVS Update: reactos
>  
>  Filip Navara wrote:
>  
> >   Alex Ionescu wrote:
> >
> > > Hi,
> > >
> > > I can't say I'm terribly overjoyed with having the /tests  
>  directory 
> >  > in /ntoskrnl. Would it be possible instead to
> > have a  
>  /tests root (on 
> > >   the new
> > > SVN server) where all the tests would go? like 
> > >  /tests/ntoskrnl, /tests/kmregtests etc...
> > >
> > >  I think it would make it a bit clearer...it just bugs me to have 
> > >  /tests in ntoskrnl. 
> >
> >  I'm personally quite happy with having tests as near as possible to 
> >  the respective component. Wine does that for years and it  
>  works very 
> >   well...
> >
> >  Regards,
> >  Filip
> >  _______________________________________________
> >  Ros-dev mailing list
> >  Ros-dev(a)reactos.com
> >  http://reactos.com:8080/mailman/listinfo/ros-dev
> >  
>  How is /tests/ntoskrnl not near? You have to remember that 
>  not everyone wants to download the tests simply for building 
>  the core kernel, or even wait for them to be compiled. Part 
>  of the new directory structure that we are working on is 
>  exactly to ease down the bandwidth for developers or users 
>  who only want the kernel. They shouldn't be bothered with an 
>  obligatory test sub-directory (ie, this is also the reason 
>  Steven removed apps/tests). The advantage of the SVN tree 
>  will be that the /tests directory will have its own 
>  repository but still be included of a master 
>  repository/makefile for those who wish to have it all.
>  
>  Best regards,
>  Alex Ionescu 
I feel really bad about you not considering tests as important
as "normal" code. I'm convinced that Extreme Programming (XP)
is the methodology for us to use and I'm set out to prove it.
XP is very good for high risk dynamic projects with varying
resources and this is exactly what ReactOS is.

If you are making a distribution and does not even bother to
run the tests before packaging it, why bother release the
possibly broken package then? If you are just monitoring
development why don't you just download one of the pre-built
packages? If you are a developer why wouldn't you want to run
the tests before a commit to make sure you didn't break
anything?

I want to make the tests an integral part of ReactOS
development. Not something that is just there because
then we can say we have tests for our software. So my
requirements are that running tests should be easy. You
write a test, then you write the domain code (the code
being tested) and finally you run the tests to make sure that
the domain code works as expected. There is no need to boot
ReactOS (in a VM or whatever) during this process so the
process is fast compared to booting ReactOS in order to test
every little change. Then you do it again and again until you
are satisfied with the result. Now you boot ReactOS and make
sure that it behaves as expected. If it does what you expect
it to then commit and go back to the first step otherwise just
go back to the first step.

See http://www.extremeprogramming.org/ for more information.

Casper