Summary on unit testing situation

[Trip Volpe]

bearophile Wrote:
> Among those four solutions the one I like more is the 'IV'. Because it keeps the work of developing the library out of the busy hands of Walter, but produces something that can have nice enough syntax, with a not too much complex compiler, and it probably allows for some future changes in how people do tests. It can also allow to write both very simple unit tests for novices or single-module programs as now, and professional/complex unit tests for harder situations or larger projects.
> 
> If you agree with me that the better solution is the IV, then those hooks/reflection have to be designed first.
> 

I definitely agree with this. The built-in unit tests are a great convenience, but the provided facilities just aren't good enough _as they are_ for actual use. Particular problems include the fact that all tests are anonymous, no detailed contextual feedback is provided, and if an assert fails in one test in a module, _all_ subsequent tests in that module will be aborted, even though this makes no sense.

I've actually been doing a bit of solution IV already for my own projects. Starting with the Runtime.moduleUnitTester() function, I've built a simple framework that runs all the unit tests in the project but keeps track of context as well, so every failure (checked with an accompanying set of non-throwing "expect" functions) is logged by module, specific test, source line, and nature of failure.

Just a few extra hooks provided to the programmer would enable the construction of some very useful unit testing on the basis of D's provided primitives (which I agree were an excellent idea). For one example, being able to name each test or otherwise associate it with some form of contextual or identifying information would be very nice.

I also posted some thoughts a while ago ( http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=105682 ) on how template alias parameters could be expanded to alias complete expressions to allow for automatic logging of the particular expression that caused an expectation failure. This is the sort of helpful diagnostic already provided by any serious C or C++ unit testing system, and it would be great to see it made possible in D.