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