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

[Dicebot 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
>
> All of this can be done with a library solution. D should have a
> very good library solution in phobos and it should be encouraged
> to use that. DMD could even know about this library and have
> special commands to trigger the tests.
>
> The problem is that you can start with "unittest" blocks, but
> then you realize you need more, so what do you do? You combine
> both? You can't!
>
> I'd say, deprecate "unittest" and write a good test library. You
> can still provide it for backwards compatibility.
>
> By the way, this is the way we do it in Crystal. The source code
> for the spec library is here, if you need some inspiration:
> https://github.com/manastech/crystal/tree/master/src/spec . It's
> just 687 lines long.

I 100% disagree. Having built-in unittest blocks have been a huge 
win for the language and greatly improved quality of library 
ecosystem. Value of standardization and availability is 
tremendous here.

Only problem is that development of the feature has stopped half 
way and there are still small bits missing here and there. All 
your requested features can be implemented within existing 
unittest feature via custom runner - while still running tests 
properly with default one!