Re: Reorganizing src/tests

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

Julio Merino <jmmv84%gmail.com@localhost> wrote:
> [...]
> > However, what would you do for kernel tests?
> 
> As I said, tests that are not easy to classify can go/remain under
> src/tests/.  I'm not concerned about what to do with such tests at
> this point -- we can decide later separately.  Should have stated this
> clearly.

OK.

> > Why? ÂConvention is consistent:
> >
> > Â Â Â Â<subdir>/<app> and /usr/tests/<subdir>/<app>
> >
> > For <app>/tests/ directory - grouping and being near the source are
> > the points, not much of "(in)consistency" there.
> 
> What do you mean?  What I proposed is exactly this: install the tests
> for subdir/app/ in /usr/tests/subdir/app/.  So, effectively,
> /usr/tests/ ends up having the same layout of src/.

For binaries, yes.

> But if you add the tests/ subdirectory to the *sources*, then
> subdir/app/tests/ must still get installed under
> /usr/tests/subdir/app/ (because the extra tests/ component here would
> be pointless), and this is not consistent.  Sure it can be made to
> work, but I smell confusion.

For sources of tests, I do not see any confusion if they would be grouped
in a separate directory, e.g. src/<subdir>/<app>/tests.

> >> 2) By introducing the tests/ subdirectory under each other directory,
> >> we are still hiding tests. ÂE.g. if I'm editing cp.c and I see right
> >> next to it a file called cp_test.c, I'll be tempted to edit it. ÂIf
> >> cp_test.c is under tests/cp_test.c, I can easily miss it. ÂNote that
> >> we don't put manual pages in a man/ subdirectory, and for a good
> >> reason. ÂOh, and directories in cvs are expensive (braindead?).
> >
> > Code should be convenient to work with. ÂHence, well organized, taking
> > into account directory level too. ÂMessing up all parts of application
> > into a single directory would be going to the opposite direction.
> 
> In most cases, the subdirectories will get in the way.  Sure, for your
> libpthread example it can make sense to split things up.  But for
> virtually all other source directories (bin, sbin, usr.bin, usr.sbin
> in particular) they provide no value because each application
> directory contains very few files.  And anyway: does it really make
> sense to split things by *file type*?  Wouldn't it make more sense to
> split them by logical concept?  E.g. a subdir for mutexes code, a
> subdir for conditions code, etc.

Maybe.  Given that there are 43 man pages and 15 .c files in libpthread,
it would be enough to move out man pages (at least for me).  For mutex
there would be only one pthread_mutex.c module. :)

> We probably shouldn't have a strict policy as to how to organize the
> tests: if for a particular subdirectory it makes sense to create a
> tests/ subdir, you can do so, but I'd like the recommended policy to
> be to not create such directories.

Sounds reasonable.  I do not see a problem to have foo_test.c and other
files in the same directory if there are only few of them (e.g. foo.c,
foo_test.c and Makefile).  Concern is to not mix up many .c and _test.c
files into a single massive directory.

-- 
Mindaugas