Re: [PATCH v3 3/7] unit-tests: add for_test

[Junio C Hamano <gitster@pobox.com>]

Kyle Lippincott <spectral@google.com> 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.