Source-Changes-D archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: src



On Mon Jul 05 2010 at 14:10:12 +0100, Julio Merino wrote:
> > Log Message:
> > Add test program that use sample code from kern/41937, and fs rump
> > helpers to check currently supported filesystems.
> >
> > t_rmdirrace (1/1): 5 test cases
> >    ext2fs_race: Passed.
> >    ffs_race: Passed.
> >    msdosfs_race: Passed.
> >    sysvbfs_race: Passed.
> >    tmpfs_race: Passed.
> 
> Neat!

Seconded!  With even a modest amount of tests our file systems should
start behaving dramatically better.  Before it was easy'ish to partially
test one file system after a global change by recompiling kernel,
rebooting, and running an admittedly ad-hoc set of tests.  With Nicolas'
work it's trivial to test all of them within seconds of saving the source
file in the editor!  (well, dunno what we would do about e.g. smbfs,
though, since there is no smb server in src, but at least the ones which
can be serviced from src can be easily handled)

> But one suggestion: test programs should have a generic name whereas
> the test cases should carry the more specific name.  This makes it
> possible to reuse a test program to provide several test cases and,
> therefore, reduces the burden of adding new test programs every time
> we want to test something.
> 
> In this particular case, it'd have made sense (imo) to name the test
> program "t_rmdir" and the test case "race".  This way, t_rmdir can
> very easily accommodate future tests for rmdir(2) without the need to
> create a test program --

I'm still very unclear about the division between test program and
test case.  It seems rather arbitrary at times.  Maybe you can point us
to a set of suggested guidelines?

> and adding a single test case is trivial, but
> adding a test program currently is not.

And minimizing this pain for myself has lead me to avoid adding new test
programs, cf. t_pr.c.


Home | Main Index | Thread Index | Old Index