You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Alan Conway <ac...@redhat.com> on 2007/05/10 15:37:39 UTC

C++ unit tests, cppunit vs. Boost.Test

I'm considering dropping cppunit and converting the unit tests to boost
test. Nothing against cppunit, but since we depend on boost anyway it
would be one less dependency. Boost has all the features, and slightly
better test macros & templates.

The only thing boost lacks is a shared-library plugin framework. I used
to think this was a great thing but I fear I was blinded by technology.
On reflection a collection of separate executables that you can directly
run individually is actually *better* that a collection of shared libs
that you can run individually using the DllPluginTester tool!

If anyone has experiences to the contrary give a shout. I'm not doing it
right away, I'll try writing a couple of tests first to see how it goes
in practice.

Cheers,
Alan.


Re: C++ unit tests, cppunit vs. Boost.Test

Posted by John O'Hara <jo...@gmail.com>.
Agree - there's just to much non-repeatability with shared libaries; just
where is LD_LIBRARY_PATH pointing in which shell...

Static linking - Reassuringly Expensive


On 10/05/07, Andrew Stitcher <as...@redhat.com> wrote:
>
> On Thu, 2007-05-10 at 09:37 -0400, Alan Conway wrote:
>
> > The only thing boost lacks is a shared-library plugin framework. I used
> > to think this was a great thing but I fear I was blinded by technology.
> > On reflection a collection of separate executables that you can directly
> > run individually is actually *better* that a collection of shared libs
> > that you can run individually using the DllPluginTester tool!
>
> I'm very glad you said that - recently John Lakos said (on a
> presentation at ACCU 2007) that you should have a standalone test
> executable per component (component has a specific meaning in his scheme
> of things). One of the reasons he cited was that the executable would
> let you know the precise set of link time dependencies of the component.
> This is important in his ideas as keeping control of component
> dependencies is paramount.
>
> Andrew
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

Re: C++ unit tests, cppunit vs. Boost.Test

Posted by Andrew Stitcher <as...@redhat.com>.
On Thu, 2007-05-10 at 09:37 -0400, Alan Conway wrote:

> The only thing boost lacks is a shared-library plugin framework. I used
> to think this was a great thing but I fear I was blinded by technology.
> On reflection a collection of separate executables that you can directly
> run individually is actually *better* that a collection of shared libs
> that you can run individually using the DllPluginTester tool!

I'm very glad you said that - recently John Lakos said (on a
presentation at ACCU 2007) that you should have a standalone test
executable per component (component has a specific meaning in his scheme
of things). One of the reasons he cited was that the executable would
let you know the precise set of link time dependencies of the component.
This is important in his ideas as keeping control of component
dependencies is paramount.

Andrew