On 5/5/14, 8:16 AM, Dicebot wrote:
On Thursday, 1 May 2014 at 19:22:36 UTC, Andrei Alexandrescu wrote:
On 5/1/14, 11:49 AM, Jacob Carlborg wrote:
On 2014-05-01 17:15, Andrei Alexandrescu wrote:
That's all nice, but I feel we're going gung ho with overengineering
already. If we give unittests names and then offer people a button
"parallelize unittests" to push (don't even specify the number of
threads! let the system figure it out depending on cores), that's a
good
step to a better world.
Sure. But on the other hand, why should D not have a great unit testing
framework built-in.
It should. My focus is to get (a) unittest names and (b) parallel
testing into the language ASAP.
Andrei
It is wrong approach. Proper one is to be able to define any sort of
test running system in library code while still being 100% compatible
with naive `dmd -unittest`. We are almost quite there, only step missing
is transferring attributes to runtime unittest block reflection.
Penalizing unittests that were bad in the first place is pretty
attractive, but propagating attributes properly is even better. -- Andrei
