Extending unittests [proposal] [Proof Of Concept]

Jonathan M Davis jmdavisProg at gmx.com
Thu Sep 20 11:58:18 PDT 2012


On Thursday, September 20, 2012 18:53:38 Johannes Pfau wrote:
> Proposal:
[snip]

In general, I'm all for instrumenting druntime such that unit testing tools 
could run unit tests individually and present their output in a customized 
manner, just so long as it doesn't really change how unit tests work now as 
far as compiling with -unittest and running your program goes. The only change 
that might be desirable would be making it so that after a unittest block 
fails, subsequent unittest blocks within its module are still run.

I _would_ point out that running any unittest blocks in a function without 
running every other unittest block before them is error prone (running further 
unittet blocks after a failure is risky enough). Last time I used JUnit, even 
though it claimed to run unitests individually and tell you the result, it 
didn't really. It might have not run all of the unit tests after the one you 
asked for, but it still ran all of the ones before it. Not doing so would be p 
problem in any situation where one unit test affects state that further unit 
tests use (much as that's arguably bad practice).

Regardless, I confess that I don't care too much about the details of how this 
sort of thing is done so long as it doesn't really change how they work from 
the standpoint of compiling with -unittest and running your executable. The 
_one_ feature that I really wish we had was the ability to name unit tests, 
since then you'd get a decent name in stack traces, but the fact that the pull 
request which makes it so that unittest block functions are named after their 
line number has finally been merged in makes that less of an issue.

- Jonathan M Davis


More information about the Digitalmars-d mailing list