Unittests and assert

[Jacob Carlborg]

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