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

[Kapps via Digitalmars-d]

On Wednesday, 1 April 2015 at 18:04:31 UTC, Ary Borenszweig wrote:
> On Monday, 30 March 2015 at 22:20:08 UTC, Andrei Alexandrescu
> wrote:
>> This is a tooling issue.
>
> I think D's built-in "unittest" blocks are a mistake.
>
> Yes, they are simple and for simple functions and algorithms 
> they
> work pretty well.
>
> However, when you have a big complex project you start having
> other needs:
> 1. Named unit-tests, so you can better find what failed
> 2. Better error messages for assertions
> 3. Better output to rerun failed tests
> 4. Setup and teardown hooks
> 5. Different outputs depending on use case
>

Everything you propose can be done with a custom unittest runner, 
using the builtin unittest blocks. Compile-time reflection + UDAs 
+ unittests is a surprisingly powerful combination, and I don't 
understand the proposals to make unittest name and such part of 
the ModuleInfo or provide special compiler support for them. Such 
an approach is not as scalable, and with compile-time reflection 
you can do anything you need with the current built-in unittest 
blocks.

The only issue I have with the way unittests are done right now, 
is the incredibly annoying requirement of having a main function 
and that main gets called. It makes generic tooling and CI 
systems much more annoying, as you have to try and guess whether 
you need to create a fake main() (or pass in -main), and worry 
about if the code is going to keep running after tests complete.