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.

On 08/10/15 9:21 PM, 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.

Yes, but:

There is no way that could conflict with serializers/vibe.d's definitions. Let alone ORM's.

+struct name
+{
+    string value;
+}

std/experimental/testing/gen_ut_main_mixin.d
Why is it not package(std.experimental.testing) and more importantly not called internal? There is nothing there which the user should be touching.

Alright seriously?
+    /**
+     * Generate green coloured output on POSIX systems
+     */
+    string green(in string msg) @safe pure const
+    {
+        return escCode(Color.green) ~ msg ~ escCode(Color.cancel);
+    }

Somebody fix please: https://github.com/robik/consoled
Irk I don't like it being done like this. I want it done right or not at all pretty much.

Further thought about UDA's especially those with high conflict potential. Perhaps they should instead be moved out into e.g. std.stdudas. That way it is not locked into e.g. testing while being reusable.

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.
> Voting ends in 2 weeks, on Oktober 22.

Sorry for being late with this but I added two comments in the PR:

One more important:

https://github.com/D-Programming-Language/phobos/pull/3207/files#r41494484

One less important:

https://github.com/D-Programming-Language/phobos/pull/3207/files#r41494229

On Thursday, 8 October 2015 at 08:52:04 UTC, Rikki Cattermole wrote:
> Alright seriously?
> +    /**
> +     * Generate green coloured output on POSIX systems
> +     */
> +    string green(in string msg) @safe pure const
> +    {
> +        return escCode(Color.green) ~ msg ~ escCode(Color.cancel);
> +    }
>
> Somebody fix please: https://github.com/robik/consoled
> Irk I don't like it being done like this. I want it done right or not at all pretty much.
>
> Further thought about UDA's especially those with high conflict potential. Perhaps they should instead be moved out into e.g. std.stdudas. That way it is not locked into e.g. testing while being reusable.

What about using compile-time-only struct-wrappers or UDA's for Visual attributes such as color, boldness, etc? For a showcase see my pretty.d (which I plan to propose to put in std.experimental.pretty):

https://github.com/nordlow/justd/blob/master/pretty.d

It has bitrotten a bit lately but I'll fix it today if you want to have live showcase.

On 09/10/15 1:12 AM, Per Nordlöw wrote:
> On Thursday, 8 October 2015 at 08:52:04 UTC, Rikki Cattermole wrote:
>> Alright seriously?
>> +    /**
>> +     * Generate green coloured output on POSIX systems
>> +     */
>> +    string green(in string msg) @safe pure const
>> +    {
>> +        return escCode(Color.green) ~ msg ~ escCode(Color.cancel);
>> +    }
>>
>> Somebody fix please: https://github.com/robik/consoled
>> Irk I don't like it being done like this. I want it done right or not
>> at all pretty much.
>>
>> Further thought about UDA's especially those with high conflict
>> potential. Perhaps they should instead be moved out into e.g.
>> std.stdudas. That way it is not locked into e.g. testing while being
>> reusable.
>
> What about using compile-time-only struct-wrappers or UDA's for Visual
> attributes such as color, boldness, etc? For a showcase see my pretty.d
> (which I plan to propose to put in std.experimental.pretty):
>
> https://github.com/nordlow/justd/blob/master/pretty.d
>
> It has bitrotten a bit lately but I'll fix it today if you want to have
> live showcase.

I don't terribly care about that :) I just hate seeing something that we should have being done privately and in Phobos.

On Thursday, 8 October 2015 at 08:52:04 UTC, Rikki Cattermole wrote:
> On 08/10/15 9:21 PM, Robert burner Schadek wrote:
>> [...]
>
> Yes, but:
>
> There is no way that could conflict with serializers/vibe.d's definitions. Let alone ORM's.

?


> std/experimental/testing/gen_ut_main_mixin.d
> Why is it not package(std.experimental.testing) and more importantly not called internal? There is nothing there which the user should be touching.

This is supposed to be used by the user.


> Alright seriously?
> +    /**
> +     * Generate green coloured output on POSIX systems
> +     */
> +    string green(in string msg) @safe pure const
> +    {
> +        return escCode(Color.green) ~ msg ~ escCode(Color.cancel);
> +    }
>
> Somebody fix please: https://github.com/robik/consoled

Get it into Phobos and I'll gladly use it.

> Further thought about UDA's especially those with high conflict potential. Perhaps they should instead be moved out into e.g. std.stdudas. That way it is not locked into e.g. testing while being reusable.

If there's a conflict, that's what the package/module system is for:

@std.experimental.testing.name unittest { ... }

Atila

On Thursday, 8 October 2015 at 08:21:58 UTC, Robert burner Schadek wrote:
> 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":

Yes

No.

As I explained before I don't like proposed API and prefer to wait until language enables cleaner implementation as opposed to making this standard.

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

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