On Tuesday, 31 March 2015 at 13:34:24 UTC, Dicebot wrote:
> On Tuesday, 31 March 2015 at 10:25:57 UTC, Idan Arye wrote:
>> I understand the preference to librarize as much as possible, but I don't think the desire to sacrifice every possible bit of convenience to avoid the tiniest changes to the language is always beneficial. I don't say that implementing everything inside the compiler is good either though, but in many cases some slight changes to the language can make the library solution so much more simple and elegant.
>>
>> In this case, allowing to name a unittest should be a very simple language change that'll make any library implementation of the rest of the feature more elegant to use, simpler to implement, and more consistent with alternative library implementations.
>
> It isn't simple at all. Name is just one of many meta-values you commonly want to attach to unittest block. Some others: description, dependency, parallelization, benchmark tag, I/O indicator. It is simply impossible to foresee it all in a language feature - but it is exactly kind of data UDA are designed for. All we need is to enhance/fix the language to actually make using of that information convenient.

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.

On Monday, 30 March 2015 at 21:58:13 UTC, Dicebot wrote:
> I'd prefer putting alternative test runner into Phobos instead which will support `@name("Something") unittest { }`

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);
}

On 3/31/15 7:45 AM, Idan Arye wrote:
> On Tuesday, 31 March 2015 at 13:34:24 UTC, Dicebot wrote:
>> On Tuesday, 31 March 2015 at 10:25:57 UTC, Idan Arye wrote:
>>> I understand the preference to librarize as much as possible, but I
>>> don't think the desire to sacrifice every possible bit of convenience
>>> to avoid the tiniest changes to the language is always beneficial. I
>>> don't say that implementing everything inside the compiler is good
>>> either though, but in many cases some slight changes to the language
>>> can make the library solution so much more simple and elegant.
>>>
>>> In this case, allowing to name a unittest should be a very simple
>>> language change that'll make any library implementation of the rest
>>> of the feature more elegant to use, simpler to implement, and more
>>> consistent with alternative library implementations.
>>
>> It isn't simple at all. Name is just one of many meta-values you
>> commonly want to attach to unittest block. Some others: description,
>> dependency, parallelization, benchmark tag, I/O indicator. It is
>> simply impossible to foresee it all in a language feature - but it is
>> exactly kind of data UDA are designed for. All we need is to
>> enhance/fix the language to actually make using of that information
>> convenient.
>
> 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.

Interesting point! -- Andrei

On 3/31/15 7:55 AM, Meta wrote:
> On Monday, 30 March 2015 at 21:58:13 UTC, Dicebot wrote:
>> I'd prefer putting alternative test runner into Phobos instead which
>> will support `@name("Something") unittest { }`
>
> 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);
> }

That's what I had in mind, too. -- Andrei

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.

-- 
/Jacob Carlborg

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

On Tuesday, 31 March 2015 at 14:13:29 UTC, Johannes Pfau wrote:
> Am Tue, 31 Mar 2015 13:31:58 +0000
> schrieb "Dicebot" <public@dicebot.lv>:
>
>> > But here's the problem:
>> >
>> > 1) The compile time approach requires some kind
>> >    of explicit registration of the unittests. At least one mixin per
>> >    module.
>> > 2) This mixin will usually provide a module constructor. But
>> >    using module constructors will cause issues with cycle detection.
>> 
>> This is not really true. You only need one mixin in the root module(s), rest can be iterated recursively by test runner itself using __traits(allMembers) reflection. Only issue with that approach is that last time I checked there was a DMD bug which prevented from getting complete list of imported modules via allMembers. Should be fixable.
>
> But then you still have to explicitly import (or at least name) all
> modules that should be tested. This is a drawback compared to the
> current builtin-unittests where you do not have to explicitly import
> to-be-tested modules.

This is true, but importing modules by name can be code that is generated. Which is exactly what I do with dtest [1] and unit-threaded [2]. It's not that big of a deal when it's part of the build system.

Atila

[1] http://code.dlang.org/my_packages/dtest
[2] http://code.dlang.org/my_packages/unit-threaded

>
> I was thinking of a fully-automated way where you only have to import a
> module (could even be object-d => no explicit import required) and
> have all tests run. This can be done by mixing in a module constructor
> in every module. From that constructor you'd call
> std.unittest.registerTest(...) and in the main function you could then
> call std.unittest.runTests(). This way you never need to name or know
> the tested modules.
>
> IIRC std.benchmark used that approach, with the drawback of manual
> mixins and module constructor cycle issues.
>
>> 
>> And module constructors are not needed at all for this, there is http://dlang.org/traits.html#getUnitTests
>
> Sure, but I was thinking about a runtime registration scheme as
> explained above.

Le 31/03/2015 20:21, Andrei Alexandrescu a écrit :
> On 3/31/15 7:45 AM, Idan Arye wrote:
>> On Tuesday, 31 March 2015 at 13:34:24 UTC, Dicebot wrote:
>>> On Tuesday, 31 March 2015 at 10:25:57 UTC, Idan Arye wrote:
>>>> I understand the preference to librarize as much as possible, but I
>>>> don't think the desire to sacrifice every possible bit of convenience
>>>> to avoid the tiniest changes to the language is always beneficial. I
>>>> don't say that implementing everything inside the compiler is good
>>>> either though, but in many cases some slight changes to the language
>>>> can make the library solution so much more simple and elegant.
>>>>
>>>> In this case, allowing to name a unittest should be a very simple
>>>> language change that'll make any library implementation of the rest
>>>> of the feature more elegant to use, simpler to implement, and more
>>>> consistent with alternative library implementations.
>>>
>>> It isn't simple at all. Name is just one of many meta-values you
>>> commonly want to attach to unittest block. Some others: description,
>>> dependency, parallelization, benchmark tag, I/O indicator. It is
>>> simply impossible to foresee it all in a language feature - but it is
>>> exactly kind of data UDA are designed for. All we need is to
>>> enhance/fix the language to actually make using of that information
>>> convenient.
>>
>> 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.
>
> Interesting point! -- Andrei
It will be nice to have named unittest.

And better if IDEs will be able to retrieve those names, to allow replay by name, displaying results by names,...

On Tuesday, 31 March 2015 at 20:04:01 UTC, 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.

Limiting unittest names to legal identifiers will save a lot of headache when we set our tools to actually use these names. Matching a legal identifier in a text stream is much easier than matching an arbitrary unicode string, even if that string is escaped.

On Tuesday, 31 March 2015 at 21:05:40 UTC, Xavier Bigand wrote:
> Le 31/03/2015 20:21, Andrei Alexandrescu a écrit :
>> On 3/31/15 7:45 AM, Idan Arye wrote:
>>> On Tuesday, 31 March 2015 at 13:34:24 UTC, Dicebot wrote:
>>>> On Tuesday, 31 March 2015 at 10:25:57 UTC, Idan Arye wrote:
>>>>> I understand the preference to librarize as much as possible, but I
>>>>> don't think the desire to sacrifice every possible bit of convenience
>>>>> to avoid the tiniest changes to the language is always beneficial. I
>>>>> don't say that implementing everything inside the compiler is good
>>>>> either though, but in many cases some slight changes to the language
>>>>> can make the library solution so much more simple and elegant.
>>>>>
>>>>> In this case, allowing to name a unittest should be a very simple
>>>>> language change that'll make any library implementation of the rest
>>>>> of the feature more elegant to use, simpler to implement, and more
>>>>> consistent with alternative library implementations.
>>>>
>>>> It isn't simple at all. Name is just one of many meta-values you
>>>> commonly want to attach to unittest block. Some others: description,
>>>> dependency, parallelization, benchmark tag, I/O indicator. It is
>>>> simply impossible to foresee it all in a language feature - but it is
>>>> exactly kind of data UDA are designed for. All we need is to
>>>> enhance/fix the language to actually make using of that information
>>>> convenient.
>>>
>>> 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.
>>
>> Interesting point! -- Andrei
> It will be nice to have named unittest.
>
> And better if IDEs will be able to retrieve those names, to allow replay by name, displaying results by names,...

Building by unittest name! Imagine - instead of placing temporary code in `main` to develop a new feature or fix a bug, you put in a named unittest and tell your IDE/build-system to only build that unittest(and whatever code needed for it to run). You `writeln` stuff to the console, and when you get some changes to output what you want you change the `writeln`s to `assert`s and proceed to work on the next step. When you are done, all you have to do is tidy it up a bit and BAM - without any special effort you get a unittest that tests that feature/bug you just worked on.