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

On Sun, Jan 26, 2014 at 07:53:30PM -0800, Andrei Alexandrescu wrote:
> On 1/26/14 3:25 AM, simendsjo wrote:
> >On Saturday, 25 January 2014 at 22:55:33 UTC, Andrei Alexandrescu wrote:
> >>There's this simple realization that unittests could (should?) be considered an intrinsic part of the build process.
> >(...)
> >
> >>In particular, this view of unittests declares our current stance on
> >>running unittests ("run unittests just before main()") as
> >>meaningless.
> >(...)
> >
> >I wouldn't mind having unittests be a part of the compilation process, but I really don't think "running before main" is useless. This lets me compile a version on my desktop and push the binary to a small VPS staging for running runtime tests. Compiling any non-trivial code on 512MB with the DMD frontend is impossible. I can also send a fully working application with unittests to a client as a beta before giving a production version.
> 
> Does it help that the client runs them every time? I.e. does the n+1th run of the unittests bring more information than the first?
[...]

It's very useful when you're in a code-compile-run development cycle, when you're likely to be making some further changes after every execution. Any regressions are quickly caught by unittests.

Obviously, it's useless to run the same unittests twice when nothing has changed, but then, I thought the idea was that you *don't* compile with -unittest when shipping the executable.


T

-- 
Once the bikeshed is up for painting, the rainbow won't suffice. -- Andrei Alexandrescu

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...

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


T

-- 
"Hi." "'Lo."

I am already doing something very similar.

When I make a module I add this to the top.
#!/usr/bin/rdmd --shebang -unittest --main
(I would like to add -cov=100 but I can't get it to work)
Then I just run the module to compile and run unit tests.

My programs with main is always very small,
typical calling a module function with the arguments.

Doing the unit testing in the end of the compile would
mean that we could ensure that dependencies  was unit testing before
use. That would be nice.

Another thing I find really tedious about D unit testing can you read about here.

http://forum.dlang.org/post/lc514a$sd7$1@digitalmars.com

Knud



On 2014-01-25 23:55, 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.
> 
> In that view, asserts inside unittests should fail with the same message format as regular compilation errors, i.e.
> 
> ./modulename.d(103): Unittest failed: user-defined message
> 
> Stack traces and other artifacts printed by failing asserts should come after, indented. An IDE user should run unittest with the usual "build" command and be able to click on the unittest failures just the same as build errors.
> 
> In particular, this view of unittests declares our current stance on running unittests ("run unittests just before main()") as meaningless. Indeed that has bothered me for quite a while - unittests are part of the build/acceptance, not part of every run. To wit, this is a growing idiom in D programs:
> 
> version(unittest) void main() {}
> else void main()
> {
>     ...
> }
> 
> What do you think? Logistically it shouldn't be too hard to arrange things to cater to this approach.
> 
> 
> Andrei


-- 
Join me on
Skype	   knudhs
Facebook   http://www.facebook.com/profile.php?id=1198821880
Linkedin   http://www.linkedin.com/pub/0/117/a54
Twitter    http://twitter.com/knudsoerensen
bitcoin donations: 13ofyUKqFL43uRJHZtNozyMVP4qxKPsAR2

I share the opinion others have expressed here that running unit tests should be the responsability of the build system.

Atila

On Saturday, 25 January 2014 at 22:55:33 UTC, 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.
>
> In that view, asserts inside unittests should fail with the same message format as regular compilation errors, i.e.
>
> ./modulename.d(103): Unittest failed: user-defined message
>
> Stack traces and other artifacts printed by failing asserts should come after, indented. An IDE user should run unittest with the usual "build" command and be able to click on the unittest failures just the same as build errors.
>
> In particular, this view of unittests declares our current stance on running unittests ("run unittests just before main()") as meaningless. Indeed that has bothered me for quite a while - unittests are part of the build/acceptance, not part of every run. To wit, this is a growing idiom in D programs:
>
> version(unittest) void main() {}
> else void main()
> {
>     ...
> }
>
> What do you think? Logistically it shouldn't be too hard to arrange things to cater to this approach.
>
>
> Andrei

> +1. Some of my unittests can only be run at runtime: like testing file
> I/O.  Obviously, other unittests can also be run at compile-time, so
> it's useful to have both.

Tests that do I/O aren't unit tests. They're more likely integration tests.

Atila

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...

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

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).

On Monday, 27 January 2014 at 11:10:04 UTC, 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...

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?)

On 2014-01-25 22:55, Andrei Alexandrescu wrote:
[Good stuff]
>
> What do you think? Logistically it shouldn't be too hard to arrange
> things to cater to this approach.

As evinced by Bugzilla 5091[0], I always run unit tests separately from the rest of the program, and so fully support this motion. As others have pointed out, there are possible problems with cross-compilation, but all in all, I think treating unit tests as a build step rather than something to do with execution is a Good Thing™.


[0]: https://d.puremagic.com/issues/show_bug.cgi?id=5091

--
  Simen