More tests running with Boost.Test than registered

I have a large solution in Visual Studio (100+) projects, of which most are dll's. The test code is in the DLL's and the tests are run using the provided console_test_runner. At the moment, each DLL has a single passing test. However, when I run the console_test_runner on a single dll, the output indicates that there are more tests. For example: D:\Projects\MyProject\console_test_runner.exe --test MyDll1.dll Running 5 test cases... *** No errors detected So I put a print statement in the test in each DLL and ran it again, and here's what happened: D:\Projects\MyProject\console_test_runner.exe --test MyDll1.dll Running 5 test cases... TestMyDll5 TestMyDll4 TestMyDll3 TestMyDll2 TestMyDll1 *** No errors detected The project for MyDll1 depends on the other projects. That can't be a coincidence! I'm confused though, why is the console_test_runner executing tests in other DLL's when I've only specified MyDll1 on the command line? Each DLL has its own unit_test_init() function declared in the pre-compiled header, so I'm really lost on what is happening here. Is it possible that the other dll tests are getting registered as well?

Jon Black <jon_black <at> fastmail.fm> writes:
So I put a print statement in the test in each DLL and ran it again, and You could have used --log_level=all to see what is being tested
The project for MyDll1 depends on the other projects. That can't be a coincidence! I'm confused though, why is the console_test_runner executing tests in other DLL's when I've only specified MyDll1 on the command line? Each DLL has its own unit_test_init() function declared in
You probably are using automatically registered test units. These are registered in single shared test framework as soon as you load these libraries and they are loaded in memory as they are dependencies of the library you want to test. Thus you end up with all test units in all loaded libraries. You can specify the test case belonging to the Mydll1 using --run=TestMyDll1 and you'll get only 1 test case being executed. I think this is correct behavior overall. What you got here is implicit dependency between test units you can't be sure TestMyDll1 working until you tested all of it's dependent test cases which are in this case reside in corresponding libraries. Gennadiy
participants (2)
-
Gennadiy Rozental
-
Jon Black