RE: [boost] Re: unit test framework

From: Mike Attili (yahoomail_at_[hidden])
Date: 2001-10-23 13:19:37

> From: Gennadiy E. Rozental [mailto:rogeeff_at_[hidden]]
> 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.

> > 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()
  { ... }
};

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.