Michael Foord <mich...@voidspace.org.uk> added the comment:
That all sounds good to me Nick. Some notes / questions.
How should parameterised tests be marked? I'm happy with a
unittest.parameterized decorator (it would do no work other than mark the test
method, with the parameterisation being done in the TestLoader).
What could the "name customisation hook" look like? A module level hook (yuck)
/ a class method hook on the TestCase that must handle every parameterised test
on that TestCase / a decorator for the parameterised test method?
If we do it at load time should we require parameterised methods to be class
methods? The alternative is to instantiate the test case when loading and
collecting the tests. Class methods won't play well with the other unittest
decorators as you can't attach attributes to classmethods. (So I guess instance
methods it is!)
If collecting tests fails part way through we should generate a failing test
that reports the exception. Should the tests collected "so far" be kept?
Should skip / expectedFail decorators still work with them? If so they'll need
custom support I expect.
If we're generating test names and then attaching these tests to TestCase
instances (so that normal test case execution will run them), should we check
for name clashes? What should we do if there is a name clash? (The generated
name would shadow an existing name.) We could prevent that by using a
non-identifier name - e.g. "${}_{}".format(name, idx)
----------
_______________________________________
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
