Unit tests in D

[Sean Kelly]

Don <nospam at nospam.com> 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.

A while back I proposed:

unittest("name") {}

As an optional way to name a unittest. It's the last function-like thing
without parens anyway.