[TIP] Reporting assertions as a way for test parametrization

[Douglas Philips]

On or about 2009 May 14, at 6:33 AM, Konrad Delong indited:

> Here's my idea on how to achieve parametrized tests. Let's not
> parametrize tests (:>), but instead make assertions report their
> results. Example is below. The code lives here
> (http://code.google.com/p/konryd-scripts/source/browse/trunk/reporting_assertion/ 
> ).
> ...

An interesting idea! I had toyed with doing something similar to that  
as well.
(collect-only isn't an issue for me.)
The problem is that things such as "self.failUnless() or even just  
returning from the test function" have two intertwined purposes:
     stopping the execution of the test -and-
     reporting the test's results.
 From a simplicity point of view, those are very often simultaneous  
events. :)

Unfortunately, unittest is not factored in a way to make teasing those  
purposes apart... easy (I see your code has to duplicate the try/ 
except code from unittest). Your decorator "bring the unittest  
exception catching and status reporting" machinery "down" into the  
middle of the call stack of the test, so they are still unified...

If there were a clean way to synthesize "new" results on the fly,  
separate from having to interrupt the flow of control (stopping  
execution of the test)... that I would find very interesting.

For the class(es) of users who need to know the number of tests up  
front, or who need accurate collection, @reporting or any other kind  
of very-late test/test-result creation probably isn't going to be very  
compelling/interesting...

--Doug