On Monday, 30 March 2015 at 23:51:17 UTC, Walter Bright wrote:
>> I'd rather see DMD automatically pass the expression that triggered the error
>> (as it is done in C) to replace this useless "Unittest failure" that forces me
>> to look through the code.
>
> You have to look at the code anyway.

My experience is that having the failing expression available speeds up the processing of figuring out what's wrong with my failing code.

That's why I'm using

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

On Monday, 30 March 2015 at 22:20:08 UTC, Andrei Alexandrescu wrote:
> In brief: I'd like to transition to a model in which unittesting is organically part of the build. After all, you wouldn't want to deploy an application that's failing its unittests.

Overall a good idea, Andrei.

I take the opportunity to share a reoccurring dream of mine which is highly related to your proposal, Andrei:

I would like to have a compiler option for *automatic persistent memoization* of unittests that are inferred to be strongly pure.

Please take a moment to think about how your usage of unittests would change if this was available.

Eventhough D compiles faster than all other languages, big projects (including my single-developer ones) will eventually grow so large that always waiting for all unittests to compile and run will not be bearable to a developer.

The idea of persistent memoziation is not new (SCons does it an elegant with build artifacts). They just haven't been applied in as many cases as they could be.

In theory it's just a matter of hashing all the code and data the a unittest depends upon and using this hash as a memoization key for remembering if the unittest failed (and perhaps also how) or now. However, I'm not sure how the memoization keys should be calculated in practise. I do however know that the ELF file format contains a BuildID attribute calculated as a SHA-1. Is there any builtin support in ELF for hashing individual functions and data (sections)? Is there at all possible to figure out what code a unittest depends upon?

Please also think about how such a builtin feature would promote establishment and usage of D from a robustness and productivity point of view.

On 4/4/15 10:38 AM, "Nordlöw" wrote:
> Please also think about how such a builtin feature would promote
> establishment and usage of D from a robustness and productivity point of
> view.

I do think it's a great idea. Sadly I also think how I have negative staff to put to work on it. -- Andrei

On Saturday, 4 April 2015 at 19:00:01 UTC, Andrei Alexandrescu wrote:
> On 4/4/15 10:38 AM, "Nordlöw" wrote:
>> Please also think about how such a builtin feature would promote
>> establishment and usage of D from a robustness and productivity point of
>> view.
>
> I do think it's a great idea. Sadly I also think how I have negative staff to put to work on it. -- Andrei

What's the reason for that?

- Lack of time?
- Fear of increased complexity that becomes difficult to maintain?
- Difficult to get it exactly right?
- Or is there something fundamentally wrong with the idea itself?

On 4/5/15 4:04 AM, "Nordlöw" wrote:
> On Saturday, 4 April 2015 at 19:00:01 UTC, Andrei Alexandrescu wrote:
>> On 4/4/15 10:38 AM, "Nordlöw" wrote:
>>> Please also think about how such a builtin feature would promote
>>> establishment and usage of D from a robustness and productivity point of
>>> view.
>>
>> I do think it's a great idea. Sadly I also think how I have negative
>> staff to put to work on it. -- Andrei
>
> What's the reason for that?
>
> - Lack of time?
> - Fear of increased complexity that becomes difficult to maintain?
> - Difficult to get it exactly right?
> - Or is there something fundamentally wrong with the idea itself?

Lack of staff, i.e. people willing and able to put boots on the ground. People following the competent and enthusiastic exchanges in the forums would be shocked to know just how few of those would be willing to actually _do_ anything for D, even the littlest thing. Nicely that doesn't include you - thanks for contributing. -- Andrei

On Monday, 30 March 2015 at 23:26:38 UTC, Dicebot wrote:
>>> And if you suggest to build both test and normal build as part of single
>>> compiler call (building test version silently in the background) this is
>>> also very confusing addition hardly worth its gain.
>>
>> Making the format of unittest failures better would take us a long way. Then we can script builds so the unittest and release build are created concurrently.
>
> If it is only format that matters you an always change it via custom test runner. For example, we do have a test runner that generates JUnit-compatible XML output for Jenkins - and that was possible to do with plain `unittest` blocks even with D1 :)
>
> Main problem with changing default formatting is that it is pretty hard to choose one that is 100% right. Current one is at least simple and predictable being just an exception printout.

I think having the default using the same format as compiler errors makes perfect sense. Providing extra formatters in Phobos, would be a huge gain, like a JUnit-compatible formatter, as it's a very widespread test reporting format that can be used with many tools.

I agree the key is the current configurability, but providing better default and better out of the box alternatives seems like a very reasonable approach to me.

On 4/6/15 3:16 PM, Leandro Lucarella wrote:
> On Monday, 30 March 2015 at 23:26:38 UTC, Dicebot wrote:
>>>> And if you suggest to build both test and normal build as part of
>>>> single
>>>> compiler call (building test version silently in the background)
>>>> this is
>>>> also very confusing addition hardly worth its gain.
>>>
>>> Making the format of unittest failures better would take us a long
>>> way. Then we can script builds so the unittest and release build are
>>> created concurrently.
>>
>> If it is only format that matters you an always change it via custom
>> test runner. For example, we do have a test runner that generates
>> JUnit-compatible XML output for Jenkins - and that was possible to do
>> with plain `unittest` blocks even with D1 :)
>>
>> Main problem with changing default formatting is that it is pretty
>> hard to choose one that is 100% right. Current one is at least simple
>> and predictable being just an exception printout.
>
> I think having the default using the same format as compiler errors
> makes perfect sense. Providing extra formatters in Phobos, would be a
> huge gain, like a JUnit-compatible formatter, as it's a very widespread
> test reporting format that can be used with many tools.
>
> I agree the key is the current configurability, but providing better
> default and better out of the box alternatives seems like a very
> reasonable approach to me.

YES! I was surprised that any of this was being debated. -- Andrei