From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2007-04-09 15:00:26
"Ari Johannesson" <ari_at_[hidden]> wrote in message
> 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
There is no single definitive answer to the best approach here. In some
regards it's matter of your personal preference. I personally wouldn't put
everything into single test module. Hundreds test modules for each test case
is also wrong direction IMO. Other than that both splitting testing into
test modules and test modules into test cases is your choice. Usually tests
structure reflect the development one. There are some obvious separators:
don't mix performance and validity tests into same test module. Don't mix
test cases that might fail to compile with the rest of the tests. Strive for
your test modules runtime to be reasonably short (up to 1 sec, for example)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk