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
