[boost] Re: boost.test covered in testing frameworks rundown

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2005-01-11 17:03:44

"Noel Llopis" <nll_pub_at_[hidden]> wrote in message
news:loom.20050111T201553-503_at_post.gmane.org...
> I've tried out the suggestions Gennadiy had for streamlining the use of
> Boost.Test fixtures and suites, and I'm extremely pleased with the
results.
>
> This is what I ended up with (compiled and tested with gcc under Linux).
> Feel free to adapt anything into Boost.Test:

[...]

I will add something along these lines.

> Now, if we can only have a unit_test_log_formatter that uses
DebugOutputString,
> that would be fantastic. I'd volunteer to look into it, but I don't use
Windows
> for development at home anymore.

Actually I realized that I may mislead you a bit. You do not need custom
formatter to direct output using DebugOutputString (unless of course you
really need different format). What you need is custom std::ostream that do
that. unit_test_log has an interface to reset output stream:

unit_test_log::instance().set_log_stream( debug_output );

> A couple of questions:
>
> What was the reason behind the choice of using the function
> init_unit_test_suite() as the initialization point? Why not let the user
create
> main() and use a very simple object to accomplish the same thing.
Something
> along these lines:
>
> int main ( int /* argc */, char* /* argv */ [] )
> {
>     test_suite * testsuite = BOOST_TEST_SUITE("Master test suite");
>     testrunner runner(testsuite);
>     return runner.run();
> }

1. If you take a look into unit_test_main.cpp you notice that there is quire
a lot of things that needs to be done before test is initialized and run
2. We want to enforce some predefined set of result codes. User may return
worng value by mistake
3. Any other solution would lead to extra work for test preparation (at
least 2 lines like you have above)
4. There may be other things in framework housekeeping that may needs to be
done pre/post test execution
5. This is common scheme used for all Boost.Test components

> That way we can do whatever we want before and after the test runs
> much more easily.

Anything you want to do pre/post your test is part of fixure, isn't it?

> Also, if I wanted to add timings around each test, where would be
> the best place to hook them up?

Including timing.

> I'm also interested in the timings
> around the whole set of tests, but that's something I could accomplish
> easily if we had an exposed main() function.

I may give you wrong result since it is including a housekeeping time. And
you could easily get this time from outside just be timing program execution

Gennadiy