Is there any pattern in the testsuite organization? There are loads of test[0-9]+. files etc. And folders are only used to group compilable/runnable...
I honestly wouldn't know where to add or search for a test case.

On 1/2/2012 9:58 AM, Trass3r wrote:
> Is there any pattern in the testsuite organization?

No.

> There are loads of
> test[0-9]+. files etc. And folders are only used to group compilable/runnable...
> I honestly wouldn't know where to add or search for a test case.

It doesn't really matter where they go. A collection of test cases with a theme to them might go in a named file, a random one might be appended to any of the test* files.

>> I honestly wouldn't know where to add or search for a test case.
> It doesn't really matter where they go. A collection of test cases with a theme to them might go in a named file, a random one might be appended to any of the test* files.

Won't this potentially lead to test duplication?
Considering that the testsuite already takes quite some time to run this isn't a desirable trend imho.

On 03-01-2012 13:36, Trass3r wrote:
>>> I honestly wouldn't know where to add or search for a test case.
>> It doesn't really matter where they go. A collection of test cases
>> with a theme to them might go in a named file, a random one might be
>> appended to any of the test* files.
>
> Won't this potentially lead to test duplication?
> Considering that the testsuite already takes quite some time to run this
> isn't a desirable trend imho.

Test duplication isn't necessarily a bad thing. In my experience, it often happens that a tiny difference between two seemingly equal tests can be all that matters.

On the other hand, grouping tests into files based on language features might be a good idea. If anything, to be able to navigate the test suite.

- Alex

On Tue, 03 Jan 2012 15:39:34 +0100, Alex Rønne Petersen <xtzgzorex@gmail.com> wrote:

> On 03-01-2012 13:36, Trass3r wrote:
>>>> I honestly wouldn't know where to add or search for a test case.
>>> It doesn't really matter where they go. A collection of test cases
>>> with a theme to them might go in a named file, a random one might be
>>> appended to any of the test* files.
>>
>> Won't this potentially lead to test duplication?
>> Considering that the testsuite already takes quite some time to run this
>> isn't a desirable trend imho.
>
> Test duplication isn't necessarily a bad thing. In my experience, it often happens that a tiny difference between two seemingly equal tests can be all that matters.
>
> On the other hand, grouping tests into files based on language features might be a good idea. If anything, to be able to navigate the test suite.
>
> - Alex

There is some opportunity in creating systematic feature tests backed
with coverage analysis. There are still too many uncovered areas.
This not only helps to find remaining bugs but gives a specification
like overview of a feature state.

On 03-01-2012 16:44, Martin Nowak wrote:
> On Tue, 03 Jan 2012 15:39:34 +0100, Alex Rønne Petersen
> <xtzgzorex@gmail.com> wrote:
>
>> On 03-01-2012 13:36, Trass3r wrote:
>>>>> I honestly wouldn't know where to add or search for a test case.
>>>> It doesn't really matter where they go. A collection of test cases
>>>> with a theme to them might go in a named file, a random one might be
>>>> appended to any of the test* files.
>>>
>>> Won't this potentially lead to test duplication?
>>> Considering that the testsuite already takes quite some time to run this
>>> isn't a desirable trend imho.
>>
>> Test duplication isn't necessarily a bad thing. In my experience, it
>> often happens that a tiny difference between two seemingly equal tests
>> can be all that matters.
>>
>> On the other hand, grouping tests into files based on language
>> features might be a good idea. If anything, to be able to navigate the
>> test suite.
>>
>> - Alex
>
> There is some opportunity in creating systematic feature tests backed
> with coverage analysis. There are still too many uncovered areas.
> This not only helps to find remaining bugs but gives a specification
> like overview of a feature state.

I still say D needs a formal specification more than a test suite as some kind of excuse for a specification. (And no, I don't consider d-p-l.org a spec; a guide at best.)

- Alex

On 1/3/12 12:57 PM, Alex Rønne Petersen wrote:
> On 03-01-2012 16:44, Martin Nowak wrote:
>> On Tue, 03 Jan 2012 15:39:34 +0100, Alex Rønne Petersen
>> <xtzgzorex@gmail.com> wrote:
>>
>>> On 03-01-2012 13:36, Trass3r wrote:
>>>>>> I honestly wouldn't know where to add or search for a test case.
>>>>> It doesn't really matter where they go. A collection of test cases
>>>>> with a theme to them might go in a named file, a random one might be
>>>>> appended to any of the test* files.
>>>>
>>>> Won't this potentially lead to test duplication?
>>>> Considering that the testsuite already takes quite some time to run
>>>> this
>>>> isn't a desirable trend imho.
>>>
>>> Test duplication isn't necessarily a bad thing. In my experience, it
>>> often happens that a tiny difference between two seemingly equal tests
>>> can be all that matters.
>>>
>>> On the other hand, grouping tests into files based on language
>>> features might be a good idea. If anything, to be able to navigate the
>>> test suite.
>>>
>>> - Alex
>>
>> There is some opportunity in creating systematic feature tests backed
>> with coverage analysis. There are still too many uncovered areas.
>> This not only helps to find remaining bugs but gives a specification
>> like overview of a feature state.
>
> I still say D needs a formal specification more than a test suite as
> some kind of excuse for a specification. (And no, I don't consider
> d-p-l.org a spec; a guide at best.)
>
> - Alex

Agreed.

Andrei

Definitely!

+1

On Tue, Jan 3, 2012 at 11:18 PM, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> On 1/3/12 12:57 PM, Alex Rønne Petersen wrote:
>>
>> On 03-01-2012 16:44, Martin Nowak wrote:
>>>
>>> On Tue, 03 Jan 2012 15:39:34 +0100, Alex Rønne Petersen <xtzgzorex@gmail.com> wrote:
>>>
>>>> On 03-01-2012 13:36, Trass3r wrote:
>>>>>>>
>>>>>>> I honestly wouldn't know where to add or search for a test case.
>>>>>>
>>>>>> It doesn't really matter where they go. A collection of test cases with a theme to them might go in a named file, a random one might be appended to any of the test* files.
>>>>>
>>>>>
>>>>> Won't this potentially lead to test duplication?
>>>>> Considering that the testsuite already takes quite some time to run
>>>>> this
>>>>> isn't a desirable trend imho.
>>>>
>>>>
>>>> Test duplication isn't necessarily a bad thing. In my experience, it often happens that a tiny difference between two seemingly equal tests can be all that matters.
>>>>
>>>> On the other hand, grouping tests into files based on language features might be a good idea. If anything, to be able to navigate the test suite.
>>>>
>>>> - Alex
>>>
>>>
>>> There is some opportunity in creating systematic feature tests backed with coverage analysis. There are still too many uncovered areas. This not only helps to find remaining bugs but gives a specification like overview of a feature state.
>>
>>
>> I still say D needs a formal specification more than a test suite as some kind of excuse for a specification. (And no, I don't consider d-p-l.org a spec; a guide at best.)
>>
>> - Alex
>
>
> Agreed.
>
> Andrei



-- 
Bye,
Gor Gyolchanyan.

On Tue, 03 Jan 2012 19:57:14 +0100, Alex Rønne Petersen <xtzgzorex@gmail.com> wrote:

> On 03-01-2012 16:44, Martin Nowak wrote:
>> On Tue, 03 Jan 2012 15:39:34 +0100, Alex Rønne Petersen
>> <xtzgzorex@gmail.com> wrote:
>>
>>> On 03-01-2012 13:36, Trass3r wrote:
>>>>>> I honestly wouldn't know where to add or search for a test case.
>>>>> It doesn't really matter where they go. A collection of test cases
>>>>> with a theme to them might go in a named file, a random one might be
>>>>> appended to any of the test* files.
>>>>
>>>> Won't this potentially lead to test duplication?
>>>> Considering that the testsuite already takes quite some time to run this
>>>> isn't a desirable trend imho.
>>>
>>> Test duplication isn't necessarily a bad thing. In my experience, it
>>> often happens that a tiny difference between two seemingly equal tests
>>> can be all that matters.
>>>
>>> On the other hand, grouping tests into files based on language
>>> features might be a good idea. If anything, to be able to navigate the
>>> test suite.
>>>
>>> - Alex
>>
>> There is some opportunity in creating systematic feature tests backed
>> with coverage analysis. There are still too many uncovered areas.
>> This not only helps to find remaining bugs but gives a specification
>> like overview of a feature state.
>
> I still say D needs a formal specification more than a test suite as some kind of excuse for a specification. (And no, I don't consider d-p-l.org a spec; a guide at best.)
>
> - Alex

I'd still like to see that the website, language specification and
specification tests become the same.