[Please do not mail me a copy of your followup] boost-users@lists.boost.org spake the secret code <87obydywlr.fsf@avasys.jp> thusly:
Now I'm starting on a few command-line utilities and would like to use Boost.Test [...]
The gist of my tests would be as follows when testing the GNU coreutils `true` and `false` utilities
BOOST_AUTO_TEST_CASE (test_false) { BOOST_CHECK_EQUAL (EXIT_FAILURE, my_system ("false")); }
BOOST_AUTO_TEST_CASE (test_true) { BOOST_CHECK_EQUAL (EXIT_SUCCESS, my_system ("true")); }
where my_system() basically does explicitly what system() would do for you.
IMO, you are approaching this all wrong. How are your unit tests going to run fast (in <100ms) if they are doing a fork/exec/system/whatever? Plus you're introducing lots of environmental dependencies on PATH, etc., that can make your tests fragile and give false failures. What I do instead is move all the entire implementation of the utility to a static library and the main() for the utility executable is just a simple delegator that calls the function in the library that does all the work. Then you can write a test executable against the static library and test everything in your utility. Instead of writing assertions against the exepcted cout/cerr of a child process, just use a stringstream that you pass into the utility library while the main() delegator passes in cout and cerr. This approach gives fast execution of unit tests, lets me easily write assertions against expected output and error messages and avoids the fragility of depending on the external execution environment. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/ Legalize Adulthood! http://legalizeadulthood.wordpress.com