From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2002-11-26 16:37:26
----- Original Message -----
From: "Rozental, Gennadiy" <gennadiy.rozental_at_[hidden]>
Sent: Monday, November 25, 2002 4:17 AM
Subject: RE: [boost] Factoring out Test Library wrapstrstream
> > My tests are already arranged in a way that 'test/minimal.hpp' offers
> > little functionality while a whole test framework, such as
> > test_execution_monitor or unit_test_framework requires me link or
> > include too many translation units.
> Well currently Boost.Test propose three configuration:
> 1. Minimal
> 2. Full linked
> 3. Full included
> Does not any one of them fit for you? What are the issues? What set of
> features you are looking for?
I'm considering the case of a single-file test which would use just a small
subset of the Test Framework.
(3) fully included
The problem with this is that I put the burden of doing so to the user.
I could use jamfiles, but jam builds doesn't work on every supported
For instance, it doesn't work on mine (borland), so I can't resort to
jamfiles to attach the test framework to a simple test with a single file.
(2) fully linked
Similarly, this requires me (and eventually the end user) to compile the
test framwwork with every platform I want to test against. This is a burden
in some cases. For example, since Borland doesn't work with bjam, I need to
do it by hand for this compiler. Similarly, I need to go through all the
trouble of building the test framework with every compiler I want to test my
code against. This is too much for a single file test which would use just a
small subset of the Test Framework.
This is potentially the best option in this scenario.
It fell short on my specific needs, but this can be easy to fix:
Specifically, I wanted it to provide the *basic* stuff at 'test_tools.hpp'
> > As a result, I don't want to use the Test
> > Library (but we could discuss this, because I might be biased by its
> > perceived complexity)
> I still hope to satisfy your requests for new features and explain
> everything that seems complex.
If I'm not mistaken, most of the stuff from test_tools.hpp can be rearranged
so that it becomes self-contained.
That is, it would be possible to use some of it by simply including
test_tools.hpp, with possibly a macro switch to indicate that its
definitions shall be included right into the translation unit being
> > A quick search for BOOST_NO_STRINGSTREAM reveals that there is a sort
> > of 'idiom' which is extensively used -by hand- among many unit tests
> > (i.e, including the appropriate header and dealing later with either
> > ostrstream or ostringstream).
> > I also found that this idiom is very well captured by the Test Library
> > under the form of the class 'wrapstrstream', which comes exactly as
> > handy as most of the unit tests I've seen need it.
> You may nor remark it but this class change the interface a little right
> after 1.29 came out to implement different fix for the issue with copy
Aha, I didn't notice it...
> > Therefore, is it possible to factor out this class so it can be used
> > standalone?
> > Say, as /utility/wrapstrstream.hpp.
> > Gennaidy, what do you think?
> > TIA,
> > Fernando Cacciola
> Well, if there is an interest in reuse of this class I do not see the
> why not. BTW at very end of 1.29 I added nullstream.hpp into details
> of Boost.Test (borrowed and reworked a bit from Daryle Walker more_io). It
> also belongs somewhere in utility.
Even if you rearrange test-tools so that it can be used standalone without
external modules that needs to be linked or added to the project, I think
that wrapstrstream() would be quite useful on its own. Using a text stream
to quickly format text on the fly is a very common operation, and
wrapstrstream() provides a nice solution for it.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk