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