[Top][All Lists]

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

test setup advice

From: tom fogal
Subject: test setup advice
Date: Mon, 27 Mar 2006 16:17:51 -0500

I'm looking for advice on how to structure a build system using

I'm writing a C++ project which I currently have just under 30
automake-based tests (e.g. check_PROGRAMS, TESTS) created.  The
structure of my build system is that all of my source files for the
program (under /src) build a `noinst' static library.  Then I compile
the file with main() and link in this `everything' library.

My /tests directory then uses that same `everything' library to link
all of the test programs against.  However the build trees for /src and
/tests are separate; the toplevel uses SUBDIRS to descend
into each of them.  The advantage of this whole setup is that adding a
test is very simple:
    1) write the test into e.g. "test.cpp"
    2) in /tests/, append "test" to a variable I have
    3) in /tests/, add a "test_SOURCES=test.cpp" line.

Unfortunately this lacks a lot of dependency information.  My new
"test" depends on the `everything' library, which is correct, but it
*really* only depends on one or two files from my /src tree.  The
upshot is that if I change anything from my /src tree, all of my tests
are recompiled.  This wouldn't be such a big deal, but C++ is
relatively slow to compile / link.  When I get 80 or so tests (which
seems like it will be quite reasonable), I imagine I won't even want to
bother running 'make check' anymore, and this will defeat the whole
purpose of my unit testing.

The solution, of course, is to drop the `everything' library and
explicitly code in the dependencies on particular files for every
individual test.  This is going to cause /tests/ to become
very large and intricate though, and thus I believe adding a test will
be a very error prone activity.  Fortunately I'm working alone on this
project, but sometimes I work with those who are less knowledgeable
about automake, and in those cases I imagine it will be more work than
its worth to maintain the dependencies in /tests/

Have others run into this problem?  Is explicitly listing the
dependencies of every check_PROGRAM really the only solution?  Are
there any tools / guides you have found useful in managing a large
suite of tests?  Maybe I should be switching to a different test

Thanks for any solutions / ideas / comments.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]