Voting for std.experimental.testing
stewart via Digitalmars-d
digitalmars-d at puremagic.com
Sun Oct 11 19:39:01 PDT 2015
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
a) Doesn't add enough value; I feel DIP83 (and also DIP82) are
more important and this library should wait then build on DIP83.
b) There'd be more bang for buck if we had good backtrace support
on all platforms when asserts fire.
c) Implements orthogonal functionality, as per Rikki's comments,
coupling a testing framework with implementation of coloured
output and report generation. Pretty output should wait until
available from other modules in Phobos.
d) API is clunky because lower-level components are not available.
e) Named unittests are nice but unless something like
unittest(name) is accepted it isn't worth it.
__FUNCITON__ already provides a UID that includes line number
information, which is 100x more useful than a name made up by Joe
Developer. If we get b) above then unittest names really become
unnecessary IMO.
bye,
stew
More information about the Digitalmars-d
mailing list