'live' testing style

[Jonathan M Davis]

On Monday, February 14, 2011 12:49:11 Tomek Sowiński wrote:
> spir napisał:
> > * Why isn't testList a unittest block?
> > 
> > Using named funcs, I can switch on & off specific test suites by
> > (un)commenting their call from the main and unique unittest block. Else,
> > either they all run, or none. During development, I only keep active the
> > test func(s) relative to the feature I'm currently working on.
> > Remedy: named unittests.
> 
> The interesting thing about named unit tests is that their names aren't
> interesting at all. They are usually dull and forced; testing filterFoo
> will be called testFilterFoo, etc. Their only purpose is to suppress
> running of unrelated tests.
> 
> Now, there is a seemingly unrelated proposal to include every ddoc'ed unit
> test in the preceding declaration as an example. This is great because it
> implies ownership -- a unit test is 'owned' by the symbol above. Going
> further, it can also be named after its owner.
> 
> module ooh;
> 
> void foo();
> 
> unittest { test foo... }
> 
> Compiling with --unittest=ooh.foo runs this unittest only. Nested control
> as a bonus: compiling with --unittest=ooh runs only the tests in module
> ooh.
> 
> So there you go, named unit tests without naming.

The number one reason that I want named unit tests is stack traces. unittest428 
or whatever a unittest block gets named to is pretty useless. So, while an 
assert within the unit test is fine, since it gives a file and line number which 
is in the unittest block, exceptions thrown from stuff called by the unit test 
become hard to track down, since you don't know which unit test was being run. 
Named unit tests would fix the problem. I believe that the best proposed syntax 
for that is

unittest(testName)
{
}

That way, something like unittest_testName would end up in the stack trace, and 
it would be easy to figure out where exception came from.

- Jonathan M Davis