One of my hobby programming projects (a programming-language experiment in the very early stages) is in C++11. At my day job, I've used the googletest framework fairly widely, and it's honestly pretty good. But I'm trying to keep my dependencies as close as possible to just the C++11 standard library, perhaps with some POSIX APIs for interactive tools.
I've also been writing a lot of Go lately - and the Go approach to testing is very bare-bones. As I've heard Rob Pike put it: "Test code is just code."
One of the things that I've noticed in working with Go is that tests tend to fall into two categories: functional and stateful.
For functional tests, I generally want the test structure to be:
1) Generate some input.
2) Call a function with the input.
3) Compare the function's output to the expected output.
4) If the comparison fails, log the input, the name of the function, and the difference between the expected and actual output.
For stateful tests, I generally want the structure to be:
1) Do some setup.
2) Call a function.
3) Compare the state after the call to the expected state.
4) If the comparison fails, log all of the relevant setup steps, the name of the function, and the difference between the expected and actual end state.
As it turns out, it's easy to express a functional test in terms of a stateful one, but not the other way around. "Do some setup" becomes "generate the input", and "the state after the call" becomes "the result returned by the call".
So now I have a clear API target: if I can make stateful tests reasonable, I can probably handle functional tests as well.
So what's next? One of my major goals in writing tests is to notice and fix and awkward usage in my API. So my test program needs to resemble a real C++ program using my API. Test setup should be C++ statements executed in ordinary program order; conditions should be C++ booleans; the test program itself should have a main() function and ordinary scoping.
I ended up writing a minimal testing package in ~135 lines of C++ and C Preprocessor. It's by no means perfect, but it's about as readable as a googletest test and the output is much more useful - if a test fails, I can figure out all of the relevant events without even needing to open the test file.