March 31, 2015
I already have a library that finds all unittest blocks (as well as its own) and names them by appending a monotonically increasing integer to mymodulename.unittest. I've been thinking of using a UDA to decorate unittest blocks so that they show up with that instead but never got around to it because I don't really use unittest blocks and nobody is asking for the feature. It'd take 30min to add though.

Obviously 1st class support would be preferable, I like the

unittest nameGoesHere {
   //...
}

that was mentioned later in the thread.

Atila

On Monday, 30 March 2015 at 21:52:35 UTC, Andrei Alexandrescu wrote:
> We're having a strong need for named unittests at Facebook for multiple reasons.
>
> 1. We have sophisticated tooling that verifies whether unittests are flaky. The automated monitor (for e.g. C++) figures whether a given unittest fails several times across several commits. Unittests are identified by name; relying on file/line is impossible because the line of a failure is not stable across changes.
>
> 2. Again for efficient automated testing and flakiness detection, one should be able to run only a subset of unittests by mentioning them by line in the command line. Note that this implies there's no interdependency between distinct unittests, which is fine because the new ability is opt-on; I'd say is pure style anyway.
>
> 3. Mentioning unittest names in failure messages helps human communication (e.g. "AddPeer is failing after your change"). This is impossible with file and line numbers.
>
> I'd like to make a DIP for named unittests. Who can help me with that?
>
>
> Andrei

March 31, 2015
On Tuesday, 31 March 2015 at 14:45:50 UTC, Idan Arye wrote:
> But unittests already have names(http://dpaste.dzfl.pl/b15e94000f15), so the only required change is to allow the user to specify that name. This should be much simpler than adding entirely new fields.

And does not really help. Of all metadata that one may want to attach to a test block, names are actually _least_ important in practice. It will be matter of time until Andrei creates new topic about adding descriptions to tests or way to mark flakey ones. Better to invest into something that scales at least a bit.
March 31, 2015
On Tuesday, 31 March 2015 at 20:18:41 UTC, Andrei Alexandrescu wrote:
> On 3/31/15 1:04 PM, Jacob Carlborg wrote:
>> On 2015-03-31 16:55, Meta wrote:
>>
>>> Aren't unittest blocks just special functions? If that's the case, there
>>> should be no problem being able to give them names. It seems to me that
>>> it would entail the lifting of a restriction rather than a real language
>>> change.
>>>
>>> Before:
>>> unittest
>>> {
>>>     assert(1 == 1);
>>> }
>>>
>>> After:
>>> unittest checkBasicLaw
>>> {
>>>     assert(1 == 1);
>>> }
>>
>> I prefer a UDA accepting a string, this can contain spaces and it's not
>> limited to identifier names.
>
> I used to think the same, but then I figured a bit of structure might be preferable. -- Andrei

I see no value in test names limited to valid identifiers. It is only tiny bit more informative than `unittestXXX` we have already. If we add names, please, let them be proper names that are easy to read.
March 31, 2015
On 03/30/2015 11:52 PM, Andrei Alexandrescu wrote:
> I'd like to make a DIP for named unittests. Who can help me with that?

Why a DIP, isn't the only question what syntax to use.

unittest (myname) vs. unittest ("mynameexpression")

> Andrei

There is an ER and an half of an implementation.

https://issues.dlang.org/show_bug.cgi?id=4747 https://github.com/D-Programming-Language/dmd/pull/1131 https://github.com/D-Programming-Language/druntime/pull/308

March 31, 2015
On Tuesday, 31 March 2015 at 21:22:09 UTC, Dicebot wrote:
> On Tuesday, 31 March 2015 at 14:45:50 UTC, Idan Arye wrote:
>> But unittests already have names(http://dpaste.dzfl.pl/b15e94000f15), so the only required change is to allow the user to specify that name. This should be much simpler than adding entirely new fields.
>
> And does not really help. Of all metadata that one may want to attach to a test block, names are actually _least_ important in practice. It will be matter of time until Andrei creates new topic about adding descriptions to tests or way to mark flakey ones. Better to invest into something that scales at least a bit.

I think you and I work under different assumptions of the goals for this feature. If we only want unittest names to be something that can be printed when the unittest runner runs the unittests, than a UDA with a string is indeed preferable. If we want something that tools can actually use to refer to a specific unittest, we need a proper identifier(yes, even though it can be implemented in library code because D is Turing-complete...)
March 31, 2015
On 3/31/15 2:50 PM, Martin Nowak wrote:
> On 03/30/2015 11:52 PM, Andrei Alexandrescu wrote:
>> I'd like to make a DIP for named unittests. Who can help me with that?
>
> Why a DIP, isn't the only question what syntax to use.
>
> unittest (myname) vs. unittest ("mynameexpression")

Also unittest myname and unittest "mynameexpression". There will be no shortage of folks willing to debate this to smithereens.

>> Andrei
>
> There is an ER and an half of an implementation.
>
> https://issues.dlang.org/show_bug.cgi?id=4747
> https://github.com/D-Programming-Language/dmd/pull/1131
> https://github.com/D-Programming-Language/druntime/pull/308

Nice, I'll check that out.


Andrei

March 31, 2015
On 3/31/15 3:28 PM, Andrei Alexandrescu wrote:
> On 3/31/15 2:50 PM, Martin Nowak wrote:
>> On 03/30/2015 11:52 PM, Andrei Alexandrescu wrote:
>>> I'd like to make a DIP for named unittests. Who can help me with that?
>>
>> Why a DIP, isn't the only question what syntax to use.
>>
>> unittest (myname) vs. unittest ("mynameexpression")
>
> Also unittest myname and unittest "mynameexpression". There will be no
> shortage of folks willing to debate this to smithereens.

One argument for myname (using standard identifier naming rules) is that it's command-line friendly: it won't require quoting when invoking a single unit test, and tends toward shorter names. It may also be more obvious that standard identifier names would use the existing lookup rules for guaranteeing uniqueness among unittest names.

One argument for "mynameexpression" is that it allows for nice descriptions (e.g. unittest "count should accept a custom comparator function").

One compromise might be something like:
    @description("count should accept a custom comparator function")
    unittest countCustomComparator
Under this example the unittest could be invoked from the command line by the countCustomComparator name or possibly by the description string as an alternative.

For the very little it's worth my bikeshed is painted without parentheses, assuming that's easily implemented.
March 31, 2015
On Tuesday, 31 March 2015 at 21:50:56 UTC, Martin Nowak wrote:
> On 03/30/2015 11:52 PM, Andrei Alexandrescu wrote:
>> I'd like to make a DIP for named unittests. Who can help me with that?
>
> Why a DIP, isn't the only question what syntax to use.
>
> unittest (myname) vs. unittest ("mynameexpression")
>
>> Andrei
>
> There is an ER and an half of an implementation.
>
> https://issues.dlang.org/show_bug.cgi?id=4747
> https://github.com/D-Programming-Language/dmd/pull/1131
> https://github.com/D-Programming-Language/druntime/pull/308

So now we are going to change the language for this ?

There is a natural name for unitests, the name of the module. We have way to break module into pieces in a backward compatible manner now, so it's all good.

We may want to add various annotation to a test, and we have UDA for that.

So the only things that is really needed is a way to customize the test runner from client code to output whatever everybody needs.
March 31, 2015
On 3/31/15 3:58 PM, deadalnix wrote:
> On Tuesday, 31 March 2015 at 21:50:56 UTC, Martin Nowak wrote:
>> On 03/30/2015 11:52 PM, Andrei Alexandrescu wrote:
>>> I'd like to make a DIP for named unittests. Who can help me with that?
>>
>> Why a DIP, isn't the only question what syntax to use.
>>
>> unittest (myname) vs. unittest ("mynameexpression")
>>
>>> Andrei
>>
>> There is an ER and an half of an implementation.
>>
>> https://issues.dlang.org/show_bug.cgi?id=4747
>> https://github.com/D-Programming-Language/dmd/pull/1131
>> https://github.com/D-Programming-Language/druntime/pull/308
>
> So now we are going to change the language for this ?
>
> There is a natural name for unitests, the name of the module. We have
> way to break module into pieces in a backward compatible manner now, so
> it's all good.
>
> We may want to add various annotation to a test, and we have UDA for that.
>
> So the only things that is really needed is a way to customize the test
> runner from client code to output whatever everybody needs.

The reasonable course is to see how far we can get with a library-only solution. Amaury, want to work on that? -- Andrei
March 31, 2015
On 03/31/2015 04:45 PM, Idan Arye wrote:
> 
> But unittests already have names(http://dpaste.dzfl.pl/b15e94000f15), so the only required change is to allow the user to specify that name. This should be much simpler than adding entirely new fields.

That's the line number, which can't be used as the OP pointed out.