Re: [boost] Boost.Test: File/build structure for Boost.Test unit

From: Dave Steffen (dgsteffen_at_[hidden])
Date: 2007-04-09 15:35:56

Late follow-up (I must have missed the original post)...

Gennadiy Rozental writes:
 > 
 > "Ari Johannesson" <ari_at_[hidden]> wrote in message 
 > news:4617C9CD.5070305_at_marimo.is...
 > > Hi,
 > >
 > > I'm using Boost.Test for unit testing a project I am working on. My
 > > question is if there is a standard way to set up and structure your unit
 > > test project.
 > >
 > > I am using Eclipse/CDT on Linux and my project is an executable shell
 > > script daemon with a bunch of classes compiled and linked into it.
 > >
 > > In order to unit test the various classes I set up another project,
 > > specifically for unit tests that compiles and links in all the classes
 > > from the main project.
 > >
 > > Now, my question is this: do I have one monolithic unittests.cpp file
 > > that for all the unit tests or should I set up multiple files which is
 > > preferable, e.g. one cpp file per class being tested.
 > >
 > > Is there a standard "best practices" way to do this?
 > 
 > This is not so much Boost.Test question, but rather generic testing 
 > organization issue.

 First: I agree with Gannadiy, this is a generic unit test issue.

 I would definitely not have one monolithic everything.  I have a
 separate .C file with a separate test suite for, roughly, each class.

 My first suggestion is to do whatever Eclipse wants you to do. :-)
 Really: do the simplest thing that your environment will let you get
 away with, and that also meets your needs.

 The only time I've done unit testing in Java was with the "standard"
 unit test framework (JTest, or something?).  The code lived in a
 directory structure under 'code'; the unit tests for the code lived
 in a parallel data structure under 'test', and Eclipse just Did The
 Right Thing.

 We don't use Eclipse; I'm an old Emacs guy.  What we do is this:
 every directory containing code also contains a Test subdirectory,
 which contains the unit tests for that code (e.g. multiple .C files,
 each of which uses Gennadiy's "auto test" setup).

 We use Jam for our build system; we have various Jam rules for
 compiling and running unit tests, compiling unit test results into
 summaries, and so forth.  Works for us.

 As for recommendations on how to write unit tests, the best thing
 I've found is NASA's Flight Code division web site,
 <http://software.gsfc.nasa.gov/process.cfm>   ... navigate down into
 their testing and correctness stuff, and look for their unit testing
 guidelines (I can't find it at the moment, but it's in there
 somewhere).

----------------------------------------------------------------------
Dave Steffen, Ph.D.       Fools ignore complexity.
Software Engineer IV      Pragmatists suffer it.
Numerica Corporation      Some can avoid it.
ph [phone] x227    Geniuses remove it.
dgsteffen_at_[hidden]            -- Alan Perlis
___________________
Numerica Disclaimer:
This message and any attachments are intended only for the individual
or entity to which the message is addressed.  It is proprietary and
may contain privileged information.  If you are neither the intended
recipient nor the agent responsible for delivering the message to the
intended recipient, you are hereby notified that any review,
retransmission, dissemination, or taking of any action in reliance
upon, the information in this communication is strictly prohibited,
and may be unlawful.  If you feel you have received this communication
in error, please notify us immediately by returning this Email to the
sender and deleting it from your computer.