In a previous post, I discussed what appeared to be my project partners' mild apprehension about using helpful CppUnit assertions like CPPUNIT_ASSERT_EQUAL(), and preferring to stick with the very raw, way less helpful Asserter::failIf(). Turns out it wasn't apprehension at all. A lot of ideas crystallized in my mind when I watched a certain programmer, within about an hour of one programming session, eliminate two compiler warnings, with the following constructs:

1. CPPUNIT_ASSERT_EQUAL( 2, aCArray.GetCount() );
2. for ( int i = 0; i < aStdVector.size(); ++i ) { /* ... */ }

The warnings:

• conversion from 'INT_PTR' to 'int', possible loss of data
• conversion from 'size_t' to 'int', possible loss of data

If you're that certain programmer, the way you fix #2 is to cast the result of size() on the std::vector to int. Sounds reasonable. And the way you fix #1 is...to discard CPPUNIT_ASSERT_EQUAL in favor of:

Asserter::failIf( aCArray.GetCount() != 2, "there were not two items" );

??!?!

But then the following occurred to me:

• If all you're going to do when a test fails is to dive right into the debugger and start checking values, you don't need the line number of the assertion that popped; you don't need to know at failure time what the actual vs. expected values are. But then again, if you're just going to dive into the debugger, why write automated tests?
• If you're not going to run every test in response to a change in your system, why are they there?
• Are they there to document usages of well-factored, isolated components of your design? If so, why not write assertions that are easier to read?
• Oh, but wide swaths of duplication, abbreviated names, and Hungarian notation are easy to read for you? Then you're a super genius...therefore you don't need the tests...therefore why write them?
• So tests are important enough to write, but not important enough to treat as first-class project citizens and keep them clean, readable, and running? Oh wait...the production code isn't clean and readable either...

Maybe I'm a code snob, but it just drives me crazy to watch people accrete terrible code time and time again, project after project, and not once look back and ask, "How can I do this better?" Clashing value systems and the aftermath of wreckage...(sigh)