Unit tests in D

[Lutger]

Don wrote:

> bearophile wrote:
>> dmd D 2.045 improves the built-in unit tests resuming their run when they
>> fail (it reports only the first failed assert for each unit test).
>> 
>> There are many features that today a professional unittest system is
>> expected to offer, I can write a long list. But in the past I have
>> explained that it's a wrong idea to try to implement all those things in
>> dmd.
>> 
>> So a good solution that has all the advantages is:
>> - To add dmd the "core" features that are both important and hard to
>> implement nicely in an external library or IDE (or make D more flexible so
>> writing such libs is possible, but this can be not easy). - To add dmd the
>> compile-time reflection, run-time reflection or hooks that external
>> unittest libs/IDEs can use to extend the built-in unit testing
>> functionality.
>> 
>> It's not easy to find such core features (that can be used by an IDE, but
>> are usable from the normal command line too), this is my first try, and I
>> can be wrong. Feel free to add items you think are necessary, or to remove
>> items you know can be implemented nicely in an external library. Later I
>> can write an enhancement request.
> 
> I think the majority of the items in your list can already be done
> fairly well (or easily enough by a library), except for giving names to
> unit tests.
> 
> One thing which you've not mentioned is in unittests for interfaces (and
> derived classes).
> I would like to be able to check that *all* implementations of an
> interface satisfy a sequence of tests.


Do you mean something like parameters for unittests?