Unittest testing assert*() calls rather than methods?

[Ben Finney]

Steven D'Aprano <steve+comp.lang.python at pearwood.info> writes:

> I used to ask the same question, but then I decided that if I wanted
> each data point to get its own tick, I should bite the bullet and
> write an individual test for each.

Hence my advocating the ‘testscenarios’ library. Have you tried that?

It allows the best of both worlds: within the class, you write a
collection of data scenarios, and write one test case for each separate
behaviour, and that's all that appears in the code; but the test run
shows every test case for every scenario.

E.g. with a ParrotTestCase class having three test cases and four
scenarios, the test run will run the full combination of all of them and
report twelve distinct test cases and the result for each.

So the “bite the bullet” you describe isn't necessary to get what you
want.

> If you really care, you could subclass unittest.TestCase, and then
> cause each assert* method to count how often it gets called. But
> really, how much detailed info about *passed* tests do you need?

The ‘testscenarios’ library does subclass the standard library
‘unittest’ module.

But as explained elsewhere, it's not the counting which is the issue.
The issue is to ensure (and report) that every test case is actually
tested in isolation against every relevant scenario.

-- 
 \            “Human reason is snatching everything to itself, leaving |
  `\              nothing for faith.” —Bernard of Clairvaux, 1090–1153 |
_o__)                                                                  |
Ben Finney