On 02/11/2011 06:02 PM, Andrei Alexandrescu wrote:
Btw to be clear: I consider code organized around loops comparing inputs with expected outputs simpler. For one thing I can see more of it, and it's obvious that only one function is tested. Then it's easier to maintain too. I consider the long copied invocations with one parameter varying indefensible in any circumstance, and I feel a mix of desperation and resignation that I need to debate this.
Right. But then, on failure, one needs to edit the testing loop to make it output needed piece(s) of information just to know what/how/why about actual test failure case. This, because we're missing a feature. Or (as I do as a workaround), build your test funcs with that information-providing statement(s), which is highly helpful (for me at least) during development phase. Then when all works fine, comment them out. On failure, just uncomment, and you'll get back all relevant info; even better, you'll get them under the same form as before (which possibly has been refined during develoment).
Denis -- _________________ vita es estrany spir.wikidot.com _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
