'''''OrganizingTestCases -- A Very Crude C++ Method'''''

-----

Sometimes I organize C++ test code as DEBUG-only code in the same files as the production code:

 File.cpp
   // Code
   #if defined(DEBUG)
   // Tests
   #endif
''...seems like the SimplestThingThatCouldPossiblyWork.  ;->''
-- JeffGrigg

Only that "DEBUG" is a bad name for the switch.

''Jeff, what if you wanted to run tests in both DEBUG and RELEASE builds. You end up creating a system where the tests must ship with the product. As a result, you've created something that seems simple but is actually complex. Tests are not just for DEBUG builds. They are even more important for RELEASE builds since the compiler optimizations and removal of assertions often cause the code to act differently.'' -- RobertDiFalco

Actually, I haven't had any problems with the release build being "untested;" I've yet to see assert() removal break code.
But then I'm very careful with what I put in assert() statements.
I wouldn't call what I've written above a "RecommendedPractice."
But it's better than nothing, and I've often found myself in situations where project management is hostile to automated regression testing.
-- JeffGrigg