Late follow-up (I must have missed the original post)... Gennadiy Rozental writes:

"Ari Johannesson" <ari@marimo.is> wrote in message news:4617C9CD.5070305@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 (970) 461-2000 x227 Geniuses remove it. dgsteffen@numerica.us -- 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.