
[Please do not mail me a copy of your followup]
boost-users@lists.boost.org spake the secret code
Richard
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