Re: unit test framework

From: Gennadiy E. Rozental (rogeeff_at_[hidden])
Date: 2001-10-23 14:49:16

--- In boost_at_y..., "Mike Attili" <yahoomail_at_a...> wrote:
> > From: Gennadiy E. Rozental [mailto:rogeeff_at_m...]
> > Subject: [boost] Re: unit test framework
> > > 2) std::distance() in parametrized_function_test_case and
> > >    paramertized_class_test_case uses the 3 argument overload 
that (I
> guess)
> > >    is a hold-over from the original STL. MSVC doesn't supply 
the 3 arg
> > >    version.
> > >    Changing it to 'stages_amount() = std::distance( begin, 
end );' works
> > >    fine.
> > Well, the thing is that standart contains both function to allow
> > compilers (like MSVC) that do not support partial specialization 
and
> > accordingly can't deduce difference_type always to use 3 arg form.
> > BUT MSVC fake result_type - it's always ptrdiff_t - and does not
> > provide 3 arg version. I was using STLPort and did not remark it. 
We
> > could put fix specifically for native MSVC STL, what you think?
> 
> In this specific context, isn't it possible to use the two arg 
version? What
> else might the return type be when counting the number of parameters
> supplied
> to a test case? If possible, that would be better than a specific 
fix for
> native MSVC STL.
There are more "fair" compilers, that do not provide 2 arg version.

> 
> > > 3) I get an assertion running unit_test_tools_test on the 
following
> line:
> > >      boost::output_test_stream output;
> > >    It calls std::fstream with a NULL pattern file name. Not 
sure what it
> > >    should be doing in this case.
> > Again, I was using STLPOrt and it allows to use NULL pointer 
(and "")
> > as an argument to fstream open, while native MSVC issue an 
assert. I
> > can't find right now whether or not it's correct you can use " " 
as
> > default argument in output_test_stream constructor
> 
> Yes, setting the pattern file name to any non-empty string avoids 
the
> assert. Thanks. Perhaps a better way is to only attempt to open
> the pattern file in the constructor if the filename is not NULL.
> 
> I also forgot to mention in the previous post that the .zip file 
puts
> all of the implementation into a directory 'lib' instead of the 
usual
> Boost convention of 'libs'.
> 
> > >
> > > I'm running MSVC 6 sp5. There are a few features that I've 
added locally
> > > that I'd like to integrate with this version of the unit test 
framework.
> In
> > > particular: auto-registration of test cases and suites,
> > I was thinking about such feature while ago. The main question is
> > WHERE to register? This desision require presence of predefined
> > test_suite. Also word automatically means that it should happend
> > statically => we should now everything statically => test 
framework
> > should be ready to accept test cases before main start and all
> > variables used to define test case (like parameter list for
> > parameterized test case) should be efined statically. All we buy 
for
> > this is that you will not need to write test_suite->add 
statement. I
> > does not seems to be worth efforts.
> 
> My interest in auto-registration comes from experience that I've had
> where unit tests were accidentally missing from the suite. It's 
common
> to see many test cases defined and then, after perhaps several 
hundred
> lines of code, the suite is created. If one of the test cases is 
omitted
> from the suite, it's difficult to tell that you should have had 133 
tests
> passed instead of 132.
> I did something like the following:
> 
> class BOOST_AUTO_TEST_SUITE(MyTestSuite)
> {
> public:
>   MyTestSuite()	{ ... }	// Optionally setup test fixture
>   ~MyTestSuite()	{ ... }	// Optionally tear down test fixture
> 
>   BOOST_UNIT_TEST(MyFirstTest)
>   { ... }
>   BOOST_UNIT_TEST(MySecondTest)
>   { ... }
>   void HelperFunction()
>   { ... }
> };

I would like to see more details on this machinery: 
BOOST_AUTO_TEST_SUITE, BOOST_UNIT_TEST

> 
> It's clear at a glance that the suite contains two test cases and 
that
> it's run automatically by the framework. This doesn't prohibit 
adding
> test suites/cases at run-time, it's just an alternative. Another 
reason
> that I use this approach is that I often have _unit_ tests for a 
library
> spread across multiple files to keep them organized and so that 
when I'm
> unit testing, I don't need to bring in a lot of headers into one 
test
> file. Using automatic registration, I don't need to update a 
separate
> top-level suite to add another unit test suite.
> If this approach goes against the spirit of the test framework, I 
could
> add it in a separate layer.
> 
> I agree with you and others that advanced functionality that impacts
> portability should be structured into optional layers. I'll put my
> thoughts on this subject together in a separate post.
> 
>    Mike Attili
>    Amaxo, Inc.

Gennadiy.