The official documentation neglects to mention that you must import the testing module for any of the testing rules to work. I put ‘using testing ;’ in my user-config.jam.
I had no trouble with the ‘unit-test’ rule, which has the same syntax as ‘exe’ but also runs the program and checks the exit status. However if you want to pass arguments or input files, you must use the ‘run’ rule, which has different syntax and seems fail if there is an exe rule for the same program. Here’s my run rule, and the corresponding exe and unit-test rules for reference:
# Original exe rule # exe dlogtest : dlogtest.cc lib/dlog.cc lib/randomhelpers.cc gmp ; # # Unit test rule # unit-test dlogtest : dlogtest.cc lib/dlog.cc lib/randomhelpers.cc gmp ; # # Run rule with argument passing run dlogtest.cc lib/dlog.cc lib/randomhelpers.cc gmp : -r -c10 : : : dlogtest ;
I’m using milestone 11 of boost-build, which does not delete the executable created by the run rule. This is actually the behavior I want. According to the changelog, this was changed in milestone 12. If you want both, you can create an exe rule with a different target name than the target for the run rule, and it should work. I think it may build the program twice though.
I don’t particularly like the way Boost.Build does testing. What if you want to run the same program multiple times with different arguments, without building it twice and having to repeat all the sources in your jam file? Or compare the output to some existing file or the output of a pre-build program installed on your system? I’m sure there is some clever way to do this, but it’s not immediately clear how. Having a way to separate building and testing would be nice. Then I could run a test that doesn’t build anything, or use a single test executable in multiple tests without rebuilding.
SCons and CMake also have fascilities for running unit tests. CMake in particular seems to have a very advanced testing framework (CTest).
