On Monday, 27 January 2014 at 12:18:55 UTC, Idan Arye wrote:
> How about exposing the sybmol of the function that runs the unittest, and having a "dunittest" tool for running the tests stored inside a regular executable? (I think it's possible?)

It is already possible via library solution.

On 1/26/14 10:08 PM, H. S. Teoh wrote:
> On Sun, Jan 26, 2014 at 08:15:23PM -0800, Andrei Alexandrescu wrote:
>> On 1/26/14 8:08 PM, Jesse Phillips wrote:
>>> On Monday, 27 January 2014 at 03:58:54 UTC, Andrei Alexandrescu wrote:
>>>> Yeppers. One other thought I had was to define a special flag e.g.
>>>> --4c5ad7908c2aa1b3de32ea25968cdf49 that says "just run unittests".
>>>
>>> I really think it would be better to use
>>> --4c5ad7908c2aa1b3de42ea25968cdf49 instead, it just makes the intent
>>> clearer.
>>
>> I'm just saying it should not clash with any application argument.
> [...]
>
> That won't work if the application is a git client looking for an SHA
> hash argument...

Of course it works unless there's a clash with this particular SHA.

> Let's not add arbitrary things like this to D programs, it doesn't
> address the issue and only introduces needless special cases.

I don't see that a special case. The only idea here is to produce one single debug executable containing unittests and running them on demand (e.g. by the build system).



Andrei

On 1/27/14 3:10 AM, Alix Pexton wrote:
> On 27/01/2014 4:15 AM, Andrei Alexandrescu wrote:
>> On 1/26/14 8:08 PM, Jesse Phillips wrote:
>>> On Monday, 27 January 2014 at 03:58:54 UTC, Andrei Alexandrescu wrote:
>>>> Yeppers. One other thought I had was to define a special flag e.g.
>>>> --4c5ad7908c2aa1b3de32ea25968cdf49 that says "just run unittests".
>>>
>>> I really think it would be better to use
>>> --4c5ad7908c2aa1b3de42ea25968cdf49 instead, it just makes the intent
>>> clearer.
>>
>> I'm just saying it should not clash with any application argument.
>>
>> Andrei
>
> Hows about making it so that unittests are only run if the executable
> name has a "_ut" suffix, or some other special name/convention?
>
> A...

Something like that would work nicely with a build system - the executable name has a specific suffix and is promoted to the non-unittest suffix once it has passed unittests.

Andrei

On 1/27/14 3:39 AM, Ary Borenszweig wrote:
> On 1/27/14, 1:04 AM, Andrei Alexandrescu wrote:
>> On 1/26/14 5:36 PM, Ary Borenszweig wrote:
>>> On 1/25/14, 7:55 PM, Andrei Alexandrescu wrote:
>>>> There's this simple realization that unittests could (should?) be
>>>> considered an intrinsic part of the build process. In order for an
>>>> executable to be worth running, it should pass the regular semantic
>>>> checks and also the unittests, which in a sense are extended semantic
>>>> checks that fall outside the traditional charter of the compiler.
>>>
>>> I can imagine someone who discovered a bug late at night, has a fix and
>>> needs to upload the new executable as soon as possible: he quickly
>>> comments all failing unit tests to make them pass. The next morning he
>>> uncomments them and fixes them with tranquility.
>>
>> The point being?
>>
>> Andrei
>>
>
> That it's annoying if you can't build an executable because some tests
> fail. Sometimes you know tests fail but you didn't have time to fix them
> (but you did fix the code).

Got it, thanks.

Andrei