On Sunday, 11 October 2015 at 21:56:21 UTC, Jonathan M Davis
wrote:
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.
That would indeed be good, and has been proposed before.
Unfortunately, we don't have that now and the idea of doing it as
a library instead (and the fact that it was considered a good
idea) came from Andrei.
As for the names they have now, they're pretty much useless for
anything whatsoever.
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.
We'd have to measure to be sure of how much worse things get. If
at all.
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).
Suggesting using `writeln` for failing tests is like telling
someone who's complaining about debugger support to "just use
printf". And then we wonder why we get complaints about our tools.
As for the cost, reasonable people may beg to differ.
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.
Why not? The druntime one is horrible.
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.
Fair enough. I don't mind using my own library, but as explained
above, there was a suggestion for making this a part of Phobos
and I included all the functionality I had, which not
coincidentally is exactly all the functionality I wanted.
As this has been rejected, I'm already thinking of smaller
simpler steps that could be made to make unit testing in D better
than it is now.
Atila
