Unittest testing assert*() calls rather than methods?

[Eric Snow]

On Wed, Sep 28, 2011 at 6:50 PM, Devin Jeanpierre
<jeanpierreda at gmail.com> wrote:
>> 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.
>
> Nearly the entire re module test suite is a list of tuples. If it was
> instead a bunch of TestCase classes, there'd be a lot more boilerplate
> to write. (At a bare minimum, there'd be two times as many lines, and
> all the extra lines would be identical...)
>
> Why is writing boilerplate for a new test a good thing? It discourages
> the authorship of tests. Make it as easy as possible by e.g. adding a
> new thing to whatever you're iterating over. This is, for example, why
> the nose test library has a decorator for generating a test suite from
> a generator.

+1

>
> Devin
>
> On Wed, Sep 28, 2011 at 8:16 PM, Steven D'Aprano
> <steve+comp.lang.python at pearwood.info> wrote:
>> Tim Chase wrote:
>>
>>> While I asked this on the Django list as it happened to be with
>>> some Django testing code, this might be a more generic Python
>>> question so I'll ask here too.
>>>
>>> When performing unittest tests, I have a number of methods of the
>>> form
>>>
>>>    def test_foo(self):
>>>      data = (
>>>        (item1, result1),
>>>        ... #bunch of tests for fence-post errors
>>>        )
>>>      for test, result in data:
>>>        self.assertEqual(process(test), result)
>>>
>>> When I run my tests, I only get a tick for running one the one
>>> test (test_foo), not the len(data) tests that were actually
>>> performed.  Is there a way for unittesting to report the number
>>> of passed-assertions rather than the number of test-methods run?
>>
>> 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.
>>
>> 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?
>>
>> If you are writing loops inside tests, you might find this anecdote useful:
>>
>> http://mail.python.org/pipermail/python-list/2011-April/1270640.html
>>
>>
>>
>> --
>> Steven
>>
>> --
>> http://mail.python.org/mailman/listinfo/python-list
>>
> --
> http://mail.python.org/mailman/listinfo/python-list
>