On 2013-02-28 08:41, Jonathan M Davis wrote:
D's unit test facilities are designed to be simple. If you want something
fancier, use a 3rd party framework of some kind.
D's unit test facilities are also designed so that they specifically print
_nothing_ on success (and as a command-line tool, this is important), so
printing out how many passed or failed will never work unless there are
failures (which may or may not conflict with what you're looking for).
I don't see why it would be a problem in printing something on success.
If you have a tool that needs to know if the tests passed or not it
should check the exit code.
Executing further unittest blocks within a file would often be nice, but it
also often would result in erroneous failures (sometimes you're stuck having
unittest blocks later in a file rely on those before, even if it's better to
avoid that), and it's complete foolishness IMHO to try and continue executing
tests within a single unittest block once one assertion fails. Even if they're
often independent, it's far to frequent that each subsequent assertion relies
on the success of the ones before. So, I'd tend to be against what you're
suggesting anyway.
I would say that if you have tests relying on other tests you're doing
it wrong. Also, you should only have one assertion per test. For
example, Rspec in the Ruby world runs the tests in random order. This is
to avoid having tests depending on each other.
--
/Jacob Carlborg
