Re: [Boost-users] [Boost.Test] C++ Unit Tests with Boost.Test, Part 1

Subject: Re: [Boost-users] [Boost.Test] C++ Unit Tests with Boost.Test, Part 1
From: Richard (legalize+jeeves_at_[hidden])
Date: 2009-07-07 12:59:46

[Please do not mail me a copy of your followup]

boost-users_at_[hidden] spake the secret code
<loom.20090707T083334-298_at_[hidden]> thusly:

>Richard <legalize+jeeves <at> mail.xmission.com> writes:
>
>> There's so much to cover on this subject and the posts were already
>> getting a bit lengthy (originally I thought it would be 1 blog post!).
>> 
>> Thanks for the feedback.
>
>And you only touched the surface ;)

Yes, there's quite a bit inside Boost.Test (thanks, BTW).  I have had
a hard time getting bootstrapped into writing tests using it, though.

My first unit tests were in NUnit and I found it very easy to become
productive right away.  At my last employer, we evaluated a bunch of
test frameworks for C++ and ended up picking Boost.Test as our
official test framework for C++.  I had been using it for a while,
mostly with BOOST_AUTO_TEST_CASE, but recently I wanted to learn more
about fixtures to extract common setup/teardown code.  I had to work
with the documentation for a while in order to figure out how to do
this.

I don't know exactly what it is about the documentation, but its
difficult for me to find stuff in there quickly.  The easier it is to
get started with a library, the more people use it.  I don't know why,
but Boost.Test feels hard to get started.  Once I got it figured out,
I decided that some tutorials would help others.

>These are very nice. I definitely need to collect references to the online
>tutorials somewhere inside Boost.Test docs.

Feel free.  I think the permalinks should be good for a long time now
that my blog is on wordpress.com.

>Didn't you mean to include single header variant of UTF in first tutorial?

I didn't want to do that because I wanted the first tutorial to cover
setting up a whole project and the way I've been doing that is to have
the dedicated main go into a single source file.  I know there are
other ways to have a "standalone single .cpp test project", but I
don't feel those cases are typical.  I always end up having one test
file per SUT (i.e. production class) with all the test cases for that
SUT in that source file.  I always end up with an EXE project and a
single main source file and one source file for each class I want to
test.

>You probably should also mention BOOST_FIXTURE_TEST_SUITE, since it's frequently
>a better way to manage fixtures.

That's covered in part 5 after I motivate its use with some
test-driven GUI development.
-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
      <http://www.xmission.com/~legalize/book/download/index.html>
      Legalize Adulthood! <http://legalizeadulthood.wordpress.com>