|
Boost : |
From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2005-01-10 10:39:37
> With that, Boot.Test definitely makes it to my list of finalists. The only
> two drawbacks I see are the reliance of some of the other Boost libraries
> (it would be ideal if something this low level could be fully
> self-contained),
Actually Boost.Test doesn't impose that many dependencies (in other case it
wouldn't be able to use it for boost internal testing).
It does depend config subsystem and some other core part of boost (like
smart_ptr for example), which are mostly targeted for TR1. But namely due to
this dependencies (not in spite of) Boost.Test achieve it's portability.
> and the verbosity needed to create suites.
See below.
> Cheers.
>
> --Noel
And here some comments to the article:
> On the downside, it's annoying to have to refer to the variables in the
> fixture through the object name. It would be great if they could somehow
> magically appear in the same scope as the test case itself. Also, it would
> have been a bit cleaner if the fixture could have been setup on the stack
by
> the BOOST_AUTO_UNIT_TEST macro instead of having to explicitly put it on
> the stack for every test case.
Here is what you could do:
#define TEST( F, test_name ) \
struct my_test ## __LINE__ : public F { \
void test_name(); \
}; \
\
void test_invoker ## __LINE__() \
{ \
my_test mt; \
mt.test_name(); \
} \
\
static boost::unit_test::ut_detail::auto_unit_test_registrar \
BOOST_JOIN( test_registrar, __LINE__) \
( boost::unit_test::create_test_case( test_invoker ## __LINE__ ,
#test_name ) ); \
\
void my_test ## __LINE__::test_name() \
/**/
And you got everything you asked for:
struct MyFixture
{
MyFixture()
{
someValue = 2.0;
str = "Hello";
}
float someValue;
std::string str;
MyTestClass myObject;
};
TEST ( MyFixture, TestCase1)
{
BOOST_CHECK_CLOSE ( someValue, 2.0f, 0.005f);
}
If you find it generally useful I could add this helper macro into
framework.
> Probably, but it's not exactly trivial to change.
> At least the default output is IDE friendly.
> I suspect I would need to dig deeper into the unit_test_log_formatter, but
I certainly didn't see a variety of preset output types that I could just
plug in.
Boost.Test supply 2 predefined log formats (human readable and XML, which
you could select by command-line) and unit_test_log_formatter interface you
could implement for you own formats. What else do you need?
> Supports suites. Yes, but with a big catch. Unless I'm missing something
> (which is very possible at this point--if so make sure to let me know),
creating a suite
> requires a bunch of fairly verbose statements
Adding test_suites usually means only something like this:
test_suite* test = BOOST_TEST_SUITE( "Master test suite" );
test_suite* ct = BOOST_TEST_SUITE( "Constructors test" );
test->add( ct );
It's not obvious how to add auto registration for suites, but if you have
ant specific proposition let us hear it.
> and also requires modifying the test runner itself in main.
I don't think that's true, or I do not understand what it means
> Have a look at the example below. Couldn't that have been
> simplified to the extreme? It's not a big deal as this is my least-wanted
requirement,
> but I wish I could label all the test cases in one file as part of a suite
with a simple macro at the beginning of the file.
You could achieve something like this:
#define SUITE( name ) \
static boost::unit_test::test_suite* suite = BOOST_TEST_SUITE( name ); \
static boost::unit_test::ut_detail::auto_unit_test_registrar \
BOOST_JOIN( test_registrar, __LINE__)( suite ); \
/**/
struct suite_registrar {
suite_registrar( test_case* tc ) { suite->add( tc ); }
};
#define TEST( name ) \
static void func_name(); \
suite_registrar \
BOOST_JOIN( suite_registrar, __LINE__) \
( BOOST_TEST_CASE( func_name ) ); \
static void func_name() \
/**/
> If you're going to be working mostly on the PC, ...., Boost.Test could be
an excellent choice.
Did you really mean that Boost.Test is only PC oriented? Or it's actually
something different? Like: "If you aren't doing embedded development..."
Regards,
Gennadiy
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk