Counting passed/failed unit tests
Jonathan M Davis
jmdavisProg at gmx.com
Wed Oct 26 10:01:18 PDT 2011
On Wednesday, October 26, 2011 08:40 David Gileadi wrote:
> On 10/25/11 4:04 AM, Jacob Carlborg wrote:
> > On 2011-10-24 22:08, Jonathan M Davis wrote:
> >> On Monday, October 24, 2011 11:23 Andrej Mitrovic wrote:
> >>> I'm not sure why it just stops after the first failing unittest
> >>> though. What is the point of that 'failed' counter?
> >>
> >> It's a long standing issue that when one unit test fails within a
> >> module, no
> >> more within that module are run (though fortunately, a while back it
> >> was fixed
> >> so that other modules' unit tests will still run). As I recall, there
> >> had to
> >> be a change to the compiler to fix it, but I don't known/remember the
> >> details.
> >> Certainly, the issue still stands.
> >>
> >> - Jonathan M Davis
> >
> > A workaround is to catch AssertErrors, hook it up with some library code
> > and you get a minimal unit test framework:
> > https://github.com/jacob-carlborg/orange/blob/master/orange/test/UnitTest
> > er.d
> >
> >
> > Example of usage:
> >
> > https://github.com/jacob-carlborg/orange/blob/master/tests/Object.d
>
> As an argument for continuing to run tests after one fails, I'm taking a
> TDD class and the instructor asserted that for unit tests you should
> generally only have one or two assertions per test method. His
> reasoning is that when something breaks you immediately know the extent
> of your breakage by counting the number of failed methods. This
> argument is pretty convincing to me.
The value of that would depend on what exactly the tests are doing -
particularly if tests require some setup - but I could see how it would be
valuable to essentially list all of the failed assertions rather than just
failed unittest blocks. However, I don't think that I'd ever do it that way
simply because the code clutter would be far too great. Even if your unit
tests consist simply of a bunch of one-liners which are just assertions
without any setup, having a unittest block per assertion is going to create a
lot of extra code, which will seriously clutter the file. Now, you have the
choice to do it either way, which is great, but I don't think that I'd want to
be leaning towards one assertion per unittest block. I'd generally favor one
unittest block per function, or at least group of related tests.
- Jonathan M Davis
More information about the Digitalmars-d
mailing list