Improving unit tests

[Don]

Sean Kelly wrote:
> Christopher Wright wrote:
>> Janderson wrote:
>>
>>> 3) If you chose "more extensible unit tests" what language features 
>>> would be needed to make this happen.
>>
>> 1. Named unittests.
>> There are a few reasons for this:
>>     - Your code should be self-documenting. unittest {} tells you 
>> nothing.
>>     - If a test fails, you want to know which test it is. A backtrace 
>> library helps more than a unittest name, I admit, but both are useful.
>>     - Naming for unittests integrates better with continuous 
>> integration servers like CruiseControl and CCNET -- these expect 
>> unittests to have fully qualified names.
> 
> I agree that this would be nice.  Perhaps unittest("name") for the syntax?
> 
>> 2. A pluggable unittest runner.
>> With this, any functionality that unittests lack can be provided. The 
>> unittest runner has to be in the runtime, of course.
> 
> There's one in druntime.
> 
>> 3. Each test should be its own function.
>> Currently, all unittest blocks in any module are conglomerated into 
>> one function, ModuleInfo.unitTest. ModuleInfo should have a list of 
>> name/function pairs. This is required for named unittests, and for 
>> reporting errors on a per-test basis.
> 
> This would be nice as well.  Recovering from unit tests currently skips 
> all tests in a module after the test that failed, which isn't terribly 
> desirable.

Couldn't there be some hidden global bool, isInUnitTest, which is set 
when the unit tests start to run, and which is set back to false when 
the last one ends. assert() could have different behaviour depending on 
whether it's in the unit testing phase, or not.