Boost logo

Boost Users :

Subject: Re: [Boost-users] testing command-line interface using Boost.Test
From: Richard (legalize+jeeves_at_[hidden])
Date: 2011-10-06 14:08:57

[Please do not mail me a copy of your followup]

boost-users_at_[hidden] spake the secret code
<87obydywlr.fsf_at_[hidden]> 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

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
      Legalize Adulthood! <>

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at