Don <nos...@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.