Gennadiy Rozental wrote:
Johan Nilsson
writes: [This is actually mainly comments to Part 2]
Richard wrote:
[Please do not mail me a copy of your followup]
http://legalizeadulthood.wordpress.com/2009/07/04/c-unit-tests-with-boost-te...
In this post, I will describe how to start making unit tests in C++ with Boost.Test.
I've only glanced through the parts, so I might have missed something. Also please note that my comments are very much from a TDD point of view.
In Part 2, you recommend using the CHECK macros by default. Being a long-time Boost.Test user (as well as a long-time TDD:er) I strongly believe that by default one should always use the REQUIRE variety of the Boost.Test macros, for a couple of reasons:
This only effectively implements single assertion per test case policy, which is what you as hardcore TDDer probably doing anyway. For all us other folks CHECK should be default level. REQUIRE should be used if you actually require one assertion to pass before you proceed to next one.
Hmm, I wouldn't describe myself as "hard-core" TDD:er but, yes, having a single assertion per test case is definitely something I aim for. Multiple assertions are ok when verifying different aspects of the same logical state, but even then such a thing can be split into multiple test cases (or fixed by adding a custom assert). As for REQUIRE vs CHECK there's another point of view IMHO; either the SUT works or it does not. Why (in automated testing) bother checking whether something "half-works"? If you are into "manually" verifying stuff by looking at and interpreting large amounts of output on the screen IMHO you're not really doing automated unit/developer testing. (Ok, so maybe I'm a "medium-core" TDD:er then :) I still can appreciate that Boost.Test can be used in many testing scenarios and strategies, of which one TDD is only one application. The series of blog posts though seems to be mainly written as an introduction on how to do test-first development with Boost.Test, even though the title starts out with "C++ Unit Tests ..." - which could mean many different things. Hence my original comments. Regards, Johan