Classicist or Mockist TDD?

You can divide TDDers in two groups - Classicist and mockist TDDers.

The first will write unit tests that are somewhat dependant and that lead to tests that rely on other tests working. The order in this is not stored (usually) making the evaluation of a test run somewhat more complicated. The tests are pretty straightforward though, no awkward mocks have to be constructed and little duplicate code is required.

The second will write unit tests that are fully independant and that lead to tests that are very quick and reliable. The order of running tests is irrelevant and the result of a test run is exactly the code that is failing. The downside is that end-to-end testing falls away and that it results in much more code for the same result.

Most people either target one or the other. You either support mocks with lots of mock support that basically pretends to be functors in a similar-but-not-quite language that is usually badly designed and very limited test support that basically just says that there's a bunch of tests and that runs them in some random order. Classicist testing usually has a fully-featured testing framework with some order-specifying things and loads of long-time taking tests that scale ever less.

For either there are *loads* of options for C++. At least 8 mocking frameworks and 35 testing frameworks, no less.

The problem with this separation is that it's pretty stupid. Either option is bad when used as the sole answer to the question of testing. You're much better off using both, when they're at their best. Use mocks for the interconnecting classes that are fairly easy to test if you take out the bottom half, use regular testing for the classes that don't lend themselves to this. For some classical tests, replace the more unusable bottom-end classes with mocks and let the rest be.

None of those 35 testing frameworks targets getting a quickly failing test, or in fact the group of people that aren't on either extreme.

You can divide TDDers in two groups - but please don't.