On 10/23/2017 4:44 AM, Martin Nowak wrote:
> On Saturday, 21 October 2017 at 22:50:51 UTC, Walter Bright wrote:
>> Coverage would give:
>>
>> 1|    x = 2;
>> 2|    if (x == 1 || x == 2)
>>
>> I.e. the second line gets an execution count of 2. By contrast,
>>
>> 1|    x = 1;
>> 1|    if (x == 1 || x == 2)
> 
> Interesting point, but would likely fail for more complex stuff.
> 
> 1| stmt;
> 2| if (api1 == 1 && api2 == 2 ||
>         api2 == 2 && api3 == 3)

There would be a separate coverage count for line 3 which would be the sum of counts for (api2 == 2) and (api3 == 3).

Generally, if this is inadequate, just split the expression into more lines.

The same thing for for loop statements and ?:


> Anyhow, I think the current state is good enough and there are gdc/ldc for further coverage features.

On Tuesday, 24 October 2017 at 20:51:36 UTC, Walter Bright wrote:
> On 10/23/2017 4:44 AM, Martin Nowak wrote:
>> On Saturday, 21 October 2017 at 22:50:51 UTC, Walter Bright wrote:
>>> Coverage would give:
>>>
>>> 1|    x = 2;
>>> 2|    if (x == 1 || x == 2)
>>>
>>> I.e. the second line gets an execution count of 2. By contrast,
>>>
>>> 1|    x = 1;
>>> 1|    if (x == 1 || x == 2)
>> 
>> Interesting point, but would likely fail for more complex stuff.
>> 
>> 1| stmt;
>> 2| if (api1 == 1 && api2 == 2 ||
>>         api2 == 2 && api3 == 3)
>
> There would be a separate coverage count for line 3 which would be the sum of counts for (api2 == 2) and (api3 == 3).
>
> Generally, if this is inadequate, just split the expression into more lines.

An example for inadequate is when you cannot see which expression is not covered:

2| if (api1 == 1 && api2 == 2 || api3 == 3)

Just splitting the expression is suggested in the blog post, but in an automatic fashion via dfmt. That is not elegant. The information is there just not expressed in a useable way.

On 10/24/2017 01:51 PM, Walter Bright wrote:
> On 10/23/2017 4:44 AM, Martin Nowak wrote:

> There would be a separate coverage count for line 3 which would be the
> sum of counts for (api2 == 2) and (api3 == 3).
>
> Generally, if this is inadequate, just split the expression into more
> lines.

It would be very useful if the compiler could do that automatically.

Ali

On 10/24/2017 3:06 PM, Ali Çehreli wrote:
> It would be very useful if the compiler could do that automatically.

On 10/24/2017 2:58 PM, qznc wrote:
> The information is there just not expressed in a useable way.


The problem is how to display it in a text file with the original source code.

On 10/24/2017 07:15 PM, Walter Bright wrote:
> On 10/24/2017 3:06 PM, Ali Çehreli wrote:
>> It would be very useful if the compiler could do that automatically.
> 
> On 10/24/2017 2:58 PM, qznc wrote:
>  > The information is there just not expressed in a useable way.
> 
> 
> The problem is how to display it in a text file with the original source code.
> 

I wouldn't mind as ugly as needed. The following original code

    if (api1 == 1 && api2 == 2 ||
        api2 == 2 && api3 == 3) {
        foo();
    }

could be broken like the following and I wouldn't mind:

    if (api1 == 1 &&
api2 == 2 ||
        api2 == 2 &&
api3 == 3) {
        foo();
    }

I would go work on the original code anyway.

Ali

On Tuesday, October 24, 2017 19:15:35 Walter Bright via Digitalmars-d- announce wrote:
> On 10/24/2017 3:06 PM, Ali Çehreli wrote:
> > It would be very useful if the compiler could do that automatically.
>
> On 10/24/2017 2:58 PM, qznc wrote:
>  > The information is there just not expressed in a useable way.
>
> The problem is how to display it in a text file with the original source code.

One option would be to add some sort of blank line (or with some kind of comment) kind of like what github does when it breaks up a line to show a diff. Github shows a line number next to the start of the actual line, and no line numbers on the subsequent lines until you get to the line that's actually the start of a new line. I don't know exactly how we'd do the same thing with an .lst file (maybe by having a line that doesn't start with |), but it at least seems like trying _something_ like that might work well. It does have the downside though that some extra lines that aren't the actual source code would in there, which may be acceptable but isn't entirely desirable.

Another option would be to present multiple numbers with + signs, e.g instead of

      5|    if(foo || bar)

do something like

      3+2|    if(foo || bar)

That might push the code farther to the right than might be desirable if you have a line with a lot of branches and/or the branches are executed a lot of times, but if someone really wants to see the info for each branch, then that's not necessarily unreasonable.

- Jonathan M Davis

On 2017-10-25 04:15, Walter Bright wrote:

> The problem is how to display it in a text file with the original source code.

An option to output the result in XML or JSON would allow an editor or IDE more options to display the result, for example, hover on different expressions to show the result.

-- 
/Jacob Carlborg

On Friday, 20 October 2017 at 14:04:25 UTC, Mike Parker wrote:

> https://dlang.org/blog/2017/10/20/unit-testing-in-action/

I'm somewhat late to this party.... but anyway, here is my two cents on the way Unit testing needs to be tweaked.

One of the values of Unit Testing is Defect Localization.

ie. In a well designed unit test suite, tell me which test failed, I will tell you, to within a few lines, where the bug is.

However in the presence of setup and teardown failures, we lose that.

Ideally we should differentiate between failures that occur during setup and teardown, versus exceptions occurring in the behaviour under test, or assertions on the validity of the result.

ie. Failures under setup and teardown are not failures of the behaviour under test. The only thing we can say about the behaviour under test in these cases is, that it “hasn’t been tested”.

Hopefully the behaviour that failed during the setup and teardown is explicitly tested elsewhere.

ie. We should stop at the first test that fails at a point other than setup and teardown, as this is likely to be the cause, for the cascade of failures in setup and teardown of other tests.