'live' testing style

[Don]

Jonathan M Davis wrote:
> 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.

Sounds as though a solution would be to have unittests automatically 
named as "_unittest" ~ __LINE__
rather than an arbitrary integer.
Wouldn't work in the case where there are two unittests on the same line:
unittest { assert(true); } unittest { assert(true); }
But we can deal with that.