Ghanshyam Thakkar <shyamthakkar001@xxxxxxxxx> writes:
> The latter provides much more context (we almost don't have to open
> t-example-decorate.c file itself in some cases to know what failed)
> than the former. Now, of course we can add more test_msg()s to the
> former to improve, but I feel that this approach of splitting them
> provides and improves the information provided on stdout _without_
> adding any of my own test_msg()s. And I think that this is a good
> middleground between cluttering the stdout vs providing very little
> context while also remaining a faithful copy of the original.
If so, why stop at having four, each of which has more than one step
that could further be split? What's the downside?
Note: Here in this review, I am not necessarily suggesting the
tests in this patch to be further split into greater number of
smaller helper functions. I am primarily interested in finding
out what the unit test framework can further do to help unit
tests written using it (i.e., like this patch). If using
finer-grained tests gives you better diagnosis, but if it is too
cumbersome to separate the tests out further, is it because the
framework is inadequate in some way? How can we improve it?
Thanks.
