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

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2007-04-09 15:00:26

"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.

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)

HTH,

Gennadiy