Author ncoghlan
Recipients Yaroslav.Halchenko, abingham, brian.curtin, eric.araujo, exarkun, fperez, michael.foord, nchauvat, ncoghlan, pitrou, r.david.murray
Date 2011-07-20.23:07:47
SpamBayes Score 8.34347e-07
Marked as misclassified No
Message-id <1311203268.54.0.54549560626.issue7897@psf.upfronthosting.co.za>
In-reply-to
Content
Load time parameterisation seems more of a worthwhile addition to me, too. As David noted, runtime parameterisation is pretty easy to do by looping and consolidating failures into the one error message via self.fail().

For test naming, trying to get too clever seems fraught with peril. I'd be happy with something like:
1. Parameterised tests are just numbered sequentially by default
2. The repr of the test parameters is included when displaying detailed error messages
3. A hook is provided to allow customisation of the naming scheme and test parameters. This hook receives an iterable of test parameters and is expected to create a new iterable producing 2-tuples of test names and parameters.

The default behaviour of the parameterised test generator could then be something like:

def parameterised_test_info(name, cases):
    for idx, case in enumerate(cases, start=1):
        yield ("{}_{}".format(name, idx), case)

The new machinery (however provided) would then take care of checking the names are unique, adding those methods to the test case, and storing the parameters somewhere convenient (likely as attributes of the created methods) for use when running the test and when displaying error messages.
History
Date User Action Args
2011-07-20 23:07:48ncoghlansetrecipients: + ncoghlan, exarkun, pitrou, eric.araujo, r.david.murray, michael.foord, brian.curtin, fperez, Yaroslav.Halchenko, nchauvat, abingham
2011-07-20 23:07:48ncoghlansetmessageid: <1311203268.54.0.54549560626.issue7897@psf.upfronthosting.co.za>
2011-07-20 23:07:47ncoghlanlinkissue7897 messages
2011-07-20 23:07:47ncoghlancreate