3 ms·
I really like INFO(); that's a nice feature I've not seen anywhere else. What are the differences between a C++ and Objective-C test framework? Is there anythi
by jmillikin 16y ago
I really like INFO(); that's a nice feature I've not seen anywhere else.
What are the differences between a C++ and Objective-C test framework? Is there anything ObjC-specific about CATCH?
Some of the other design choices here I've used, and later abandoned, in my own testing libraries:
> The assertion macro is REQUIRE( expression ), rather than the, now traditional, REQUIRE_EQUALS( lhs, rhs ), or similar. Don't worry - lhs and rhs are captured anyway - more on this later.
Using C++ operators for assertions is very limiting; some interesting assertions, like floating-point near-equality, have no operator and thus must be tested separately. I like to use separate functions to build "assertion results", so you can get code equivalent to:
REQUIRE(equal(lhs, rhs));
REQUIRE(equal_within(lhs, rhs, 0.001));
REQUIRE(not_null(lhs));
and so on. With this style, you also get multi-variable assertions and value capture for free.
> We didn't name the function. We named the test case. This frees us from couching our names in legal C++ identifiers. We also provide a longer form description that serves as an active comment
It can be nice to have a description of the test case, but free-form names like you have are a major pain to write out on the command line if you're running a particular set of tests during development. If you want a description, allow it in addition to the test name.
- phil_nash 16y agoFloating point comparisons are achieved through the Approx helper class. E.g: REQUIRE( pi == Approx( 3.14159265358 ) ); (and yes, I know pi to a lot more digits than that!) The style you suggest is almost supported out of the box, and I've been considering fully supporting it - especially for container oriented tests. As to the test naming - the idea is that you provide a short, hierarchical name, and a longer description (so the description is in addition to the test name): TEST_CASE( "example/test1", "Such and such should do so and so" ) To run a test you need only specify the name (example/test1) - or a part of the name (e.g. example/*) (allowing tests to be easily grouped into suites with no extra work).