Re: [boost] Factoring out Test Library wrapstrstream

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2002-11-26 16:37:26

----- Original Message -----
From: "Rozental, Gennadiy" <gennadiy.rozental_at_[hidden]>
To: <boost_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
too
> > 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
platform.
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.

(1) Minimal
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.
>
Great.
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
compiled.

> > 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
> constructor.
>
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
reason
> why not. BTW at very end of 1.29 I added nullstream.hpp into details
section
> 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.

Best regards,

Fernando Cacciola