Nick Coghlan <ncogh...@gmail.com> added the comment:
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.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue7897>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
