Hi Eugene, Eugene Wee wrote:

On Sun, May 10, 2009 at 7:52 PM, Ruediger Berlich <ruediger.berlich@iwr.fzk.de> wrote:

...

I would now like to make sure that tests are run in a specific order. After all these are unit tests, and I want the most basic components to be tested first.

Why not make the tests independent so that they can be run in any order?

Regards, Eugene

if I understand you correctly you suggest to organize tests for each class in its own executable and to run them separately, e.g. from a script. This would definitely be an option, so I'll resort to that when no other possibility is available. However, there must be some component in Boost.Test which chooses in which order tests are executed. It does not appear to be the linking order (I have tried that). Hence I was just wondering whether ther was an easy way to influence the execution order (which would then save me a few hours). Alphabetic order ? In any case thanks, Ruediger

Tim Day wrote:

If I grep my /usr/include/boost/test (I'm still on 1.35) for "depend" then I'm intrigued to see there appears to be some sort of support for declaring dependencies between tests (which would presumably influence the order)

No. Not at the moment. If you believe this needs t obe fixed please submit bug report.

e.g in unit_test_suite_impl.hpp test_unit has a depends_on method taking (a pointer to) another test_unit as an argument. I haven't tried doing anything with it though. Would be interested to know more... it doesn't seem to be documented.

Essentially it's single method in test_unit: void depends_on( test_unit* tu );

I can sympathise with wanting to run tests in a specific order. I generally like to run the quick (typically low level) ones first, and leave the slow ones until later. My preferred solution is to maintain two test executables; one with the tests quick enough to be run after every compile, the other (which might take some 10s of seconds) is better run on demand (after making big changes, before commits).

You can maintain one executable and select est cases to run with command line parameter. For example: test_module.exe --run=*/basic_test only executes test cases named basic_test in all test suites Gennadiy

Dear Gennadiy. thanks a lot. This is very helpful! Best Regards, Ruediger Gennadiy Rozental wrote:

Ruediger Berlich wrote:

...

Hi there,

I am using Boost.Test to run Unit tests for my code (Boost 1.39). For each class, I have a number of tests (implemented through BOOST_AUTO_TEST_CASE or BOOST_AUTO_TEST_CASE_TEMPLATE, respectively), organized in test suites (arranged in BOOST_AUTO_TEST_SUITE blocks). Each BOOST_AUTO_TEST_SUITE with the associated AUTO_TESTs is a separate compilation unit, thus localted in its own file.

An execution order is defined by the test tree structure, which in turn is defined by the order of the registration calls. When using manual registration you can carve you own order. If you employ automatic registration the only thing we can promise is the order of test cases within the same test file. I am not aware about the means to force particular global order of static initializers.

...

Is there a way to do this with the AUTO-environment, or do I have to resort to manual registration of test suites and/or test cases ?

You can use --run command line parameter to filter out only basic test units in first call and advanced test in second.

Boost.Test does support test unit dependency. But:

a) It only supported easily for manually registered test units. For automatically registered ones you'll need to jump through some hoops (for example you can define dependency in global fixture)

b) Dependency does not actually affect test units order execution. This require potentially complicated reordering of the test tree, which is not implemented yet.

Gennadiy