Kyle Lippincott <spectral@xxxxxxxxxx> writes: >> > Maybe it's because I'm coming from a C++ environment at >> > $JOB that's using Google's gunit and gmock frameworks, where every >> > test is in its own function and we usually don't even write the main >> > function ourselves, but I have a preference for the separate >> > functions. >> >> If we do not have to write the main at all, then it would make the >> separate function that implements a single test a lot more palatable, >> and we do not even have to implement and call TEST() macro ;-). > ... > I tried to think of a way to do > this, and they all involved some other system coming along and > identifying the tests and code-generating a main function, which also > seems like too much magic to me. I thought that automatically generating the boilerplates from the visible list of test functions and piecing them together with a synthetic main was what was brought up as how libgit2 project does this? It does not sound all that involved and I do not find it a rocket science. In any case, a well written framework soon becomes "magic" anyway. Our scripted test suite, back when Pasky and I invented it, was unknown to many people, would have looked very far away from any day-to-day shell scripts, and are full of magic. Modern versions gained even more magic than the what we had in the olden days. But I hear these days other projects imitate the pattern, so it may no longer so much "magic" to many audiences. If we use a well-written framework for C unit tests, I suspect that the same thing would happen eventually. An important point is the "well-written" part, which needs to hide the ugly implementation details well without revealing it in corners. As Phillip said, a loop construct similar to for() that you are not allowed to break or continue may not qualify exactly for that reason.
