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/[email protected]
Previous Thread:
http://forum.dlang.org/post/[email protected]
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
