Parallel execution of unittests

[Orvid King via Digitalmars-d]

As a note, I'm one of those that have used the main function in
addition to unittests. I use it in the unittest build mode of my JSON
serialization library, using the unittests to ensure I didn't break
anything, and then using the main to run a performance test that my
changes actually did make it faster.

On 4/30/14, H. S. Teoh via Digitalmars-d <digitalmars-d at puremagic.com> wrote:
> On Wed, Apr 30, 2014 at 08:43:31AM -0700, Andrei Alexandrescu via
> Digitalmars-d wrote:
> [...]
>> Last but not least, virtually nobody I know runs unittests and then
>> main.  This is quickly becoming an idiom:
>>
>> version(unittest) void main() {}
>> else void main()
>> {
>>    ...
>> }
>>
>> I think it's time to change that. We could do it the
>> non-backward-compatible way by redefining -unittest to instruct the
>> compiler to not run main. Or we could define another flag such as
>> -unittest-only and then deprecate the existing one.
> [...]
>
> Actually, I still run unittests before main. :) When I want to *not* run
> unittests, I just recompile with -release (and no -unittest).
>
> The nice thing about unittests running before main is that during the
> code-compile-test cycle I can have the unittests run *and* manually test
> the program afterwards -- usually in this case I only run the program
> once before modifying the code and recompiling, so it would be needless
> work to have to compile the program twice (once for unittests, once for
> main).
>
> An alternative, perhaps nicer, idea is to have a *runtime* switch to run
> unittests, recognized by druntime, perhaps something like:
>
> 	./program --pragma-druntime-run-unittests
>
> Or something similarly unlikely to clash with real options accepted by
> the program.
>
>
> T
>
> --
> Genius may have its limitations, but stupidity is not thus handicapped. --
> Elbert Hubbard
>