unittests are really part of the build, not a special run

Andrei Alexandrescu via Digitalmars-d digitalmars-d at puremagic.com
Mon Mar 30 15:20:07 PDT 2015

This is a tooling issue.

D builds and messaging are rigged to consider unittests as a special 
build followed by a special run of an application.

In brief: I'd like to transition to a model in which unittesting is 
organically part of the build. After all, you wouldn't want to deploy an 
application that's failing its unittests.

Detail: Consider running a build vs. a unittest in one of the supported 
editors/IDEs (emacs, vim, Code:Blocks, Visual D, Xamarin...). During a 
build, an error will come in a standard format, e.g.

std/array.d(39): Error: undefined identifier xyz

This format is recognized by the editor and allows the user to click on 
it and go straight to the offending line etc.

In contrast, a failing unittest has a completely different format. In 
fact, it's a format that's worse than useless because it confuses the 

core.exception.AssertError at std/array.d(39): xyz

emacs will recognize the text as a filename and upon clicking would ask 
the user to open the nonsense file 
"core.exception.AssertError at std/array.d". This error line is followed by 
a stacktrace, which is in no recognizable format. It should be in the 
format of e.g. gcc remarks providing additional information for an 
error, and again provide file/line information so the user can click and 
see the call stack in the source.

Where I want us to be is a place where unittests are considered a part 
of the build; it should be trivial to set things up such that 
unittesting is virtually indistinguishable from compilation and linking.

This all is relatively easy to implement but might have a large positive 

Please chime in before I make this into an issue. Anyone would like to 
take this?


More information about the Digitalmars-d mailing list