Voting for std.experimental.testing

[Jonathan M Davis via Digitalmars-d]

On Thursday, 8 October 2015 at 08:21:58 UTC, Robert burner 
Schadek wrote:
> This is the voting thread for inclusion of 
> std.experimental.testing into phobos.
>
> PR: https://github.com/D-Programming-Language/phobos/pull/3207
> Dub: http://code.dlang.org/packages/unit-threaded
> Doc: See CyberShadow/DAutoTest for up-to-date documentation 
> build
> Formal Review Thread: 
> http://forum.dlang.org/post/stbdckpfsysjtppldmry@forum.dlang.org
> Previous Thread: 
> http://forum.dlang.org/post/uzocokshugchescbawlj@forum.dlang.org
>
> Please respond to this post with a comment starting with a 
> single "Yes"/"No" and optional explanation after that. Criteria 
> you are expected to evaluate as part of "Yes":
>
> - is this functionality needed in Phobos
> - is basic design sound (some breaking changes are OK for 
> std.experimental but not full redesign)
>
> As usual, anyone can vote, but opinions of Phobos developers 
> hold more value.
>
> Voting ends in 2 weeks, on Oktober 22.

No.

Given that unittest blocks already have function names (it's just 
that you can't name them directly), it's kind of ridiculous IMHO 
to use attributes for that. We should just make it possible to do 
something like unittest(funcName) {} to name the unittest blocks.

I also think that most of the functionality that 
std.expermental.testing provides is completely unnecessary - e.g. 
std.experimental.testing.should contains a bunch of functions 
that can almost always easily be done by simply using an 
assertion, and my experience with templated assertion functions 
like this is that they bloat things considerably, increasing 
compilation time and the amount of memory required. They're not 
worth the cost unless they significantly reduce the amount of 
code required to write a test (which these don't). If all that's 
needed is the ability to print out more information on failure, 
that's easily added by adding some writeln statements and 
rerunning the tests (on top of the fact that there's currently a 
DIP for how to improve assertion messages to solve that problem; 
and if that gets approved, then these functions make even less 
sense).

Being able to parallelize unit tests would be nice, but we should 
be able to add that to the existing test runner in druntime 
easily enough. And I definitely don't like the idea of adding 
another test runner into Phobos to replace the one in druntime. 
If there are some relatively simple changes that can be made to 
the one in druntime to get the improvements that we want, then 
great. We should add them there. But I don't think that we should 
be adding stuff to Phobos to replace the unit test stuff in 
druntime, and I think that if someone wants to have something 
that's definitely more complicated or works significantly 
differently from the unit test framework in druntime, then that 
should be handle by 3rd party libs and not included as part of 
the official libraries.

- Jonathan M Davis