bearophile wrote: > Jonathan M Davis: > >> Most of the rest (if not all of it) could indeed be done in a library. > > I am not sure it could be done nicely too :-) > > >> Right now >> unit tests follow the unix convention of saying nothing on success, > > That's an usability failure. Humans expect feedback, because you can't > tell apart "unittests run and succeed" from "unittests not even run". That > Unix convention is bad here. And Unix commands sometimes have a -v > (verbose) command that gives feedback, while D unittests don't have this > option.
Actually the unix convention is to give exit code 0 as an indicator of success, so there is feedback. It is very usable for scripting. But with the change Sean suggested - and I assume an extension point in druntime - there would be enough for a more human friendly tool to be built on top of the current D unittesting system. >> particularly when it's not all that hard >> to add code yourself which prints out success if you really want it to. > > It's also not hard to define global functions, wrapped in a > version(unittest){}, to replace the need of the unittest keyword (unittest > becomes a version ID). > > Bye, > bearophile