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
editor:
core.exception.AssertError@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@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
impact.
Please chime in before I make this into an issue. Anyone would like to
take this?
Andrei
