[issue12600] Support parameterized TestCases in unittest

R. David Murray added the comment: I'd still like to see a recipe for creating parameterized test cases via load_tests added to the docs. It may be relatively obvious how to do it once you think of it, but it isn't obvious to a relative newcomer that you *can* do it, and it would make a grea

[issue12600] Support parameterized TestCases in unittest

Nick Coghlan added the comment: Back on topic... While I can see the advantage of parameterisation at the level of individual tests, I'm not at all clear on the benefits at the TestCase level. For CPython's own test suite, if we want to share tests amongst multiple test cases, we just use or

[issue12600] Support parameterized TestCases in unittest

Nick Coghlan added the comment: Mark, please stop discussing per-run parameters in this issue. Those are NOT the kind of parameters we're talking about (and are easily handled via a global settings module, anyway, the exact same way you can handle process global settings for *any* kind of app

[issue12600] Support parameterized TestCases in unittest

Mark Diekhans added the comment: Allowing loadTestsFromTestCase() to take either a testCaseClass or a (testCaseClass, param) tuple, where the param is then past to the __init__ function might do the trick. One param is sufficient, since it can be a container for any number of params. This allo

[issue12600] Support parameterized TestCases in unittest

R. David Murray added the comment: That's not the kind of parameterization this ticket is about, though. You are talking about passing data in to a test run from the command line (or other source), which is a different issue (though the implementations might share some common infrastructure)

[issue12600] Support parameterized TestCases in unittest

Mark Diekhans added the comment: > R. David Murray added the comment: > > Meaning you want to run the same test suite with a variety of > different DB connections? That seems like a reasonable use > case. This is for external parameterization of a test to run in a different environment. Int

[issue12600] Support parameterized TestCases in unittest

R. David Murray added the comment: Maybe we could add a recipe for doing this to the load_tests docs? I don't think that load_tests is going to be more readable, though, since it doesn't allow you to put the parameterization next to the class you are parameterizing (unless you do some additio

[issue12600] Support parameterized TestCases in unittest

Michael Foord added the comment: Why not create a simple TestCase factory in load_tests? Before a patch can be produced a clean api that offers a clear benefit over the TestCase factory needs to be proposed. -- ___ Python tracker

[issue12600] Support parameterized TestCases in unittest

Éric Araujo added the comment: Mark, would you like to work on a patch for this? -- ___ Python tracker ___ ___ Python-bugs-list maili

[issue12600] Support parameterized TestCases in unittest

R. David Murray added the comment: Drat, the tracker lost my post. In summary, given a concrete use case (running a test case with a variety of different DB connections) and the improved readablility for the common case of just changing class constants in the 'parameterized' subclasses, I'd

[issue12600] Support parameterized TestCases in unittest

R. David Murray added the comment: Meaning you want to run the same test suite with a variety of different DB connections? That seems like a reasonable use case. Personally I find that while I sometimes create subclasses to adjust certain class parameters (thus creating a parameterized test

[issue12600] Support parameterized TestCases in unittest

Mark Diekhans added the comment: The lack of the ability to pass a parameter to a test case is a very frustrating restriction with unittest. The frequent need if for a database connection for testing database related classes. Yes, there are lots of other ways to work around it, but they tend to

[issue12600] Support parameterized TestCases in unittest

Changes by Pere Martir : -- nosy: +pere.martir ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue12600] Support parameterized TestCases in unittest

Michael Foord added the comment: Having a "TestCase factory" would be pretty easy, and solve the scaling problems. For example: def make_testcase_classes(): for backend in backends: yield type( '{}Test'.format(backend.name), (TheBaseClass, unittest.TestCase

[issue12600] Support parameterized TestCases in unittest

Austin Bingham added the comment: Yes, in some sense that's what I'm thinking of. But one problem with this straightforward approach is that it doesn't scale well. If I've got many TestCases, each if which I want to parameterize, I have to create subclasses for each parameterization. If I add a

[issue12600] Support parameterized TestCases in unittest

R. David Murray added the comment: Yes, except that it would be: class PostgressDB2Testcase(AbstractDB2Testcase, unittest.TestCasse): The fact that other test frameworks have found it worth implementing indicates there *might* be something worthwhile there, but unless someone makes the cas

[issue12600] Support parameterized TestCases in unittest

Terry J. Reedy added the comment: David, is this the sort of thing you mean? @skip # so do not run without backend class AbstractDB2Testcase: backend = None class PostgressDB2Testcase(AbstractDB2Testcase): backend = postgress # well, enough info to fine it ... If so, I think we should

[issue12600] Support parameterized TestCases in unittest

Michael Foord added the comment: Yeah, without some clear advantages and a clean api / implementation I'm -1. -- ___ Python tracker ___ _

[issue12600] Support parameterized TestCases in unittest

Antoine Pitrou added the comment: > Note that this is fairly simple to do now via subclassing, so any > proposed API would need to show a clear benefit over that approach to > be worth the extra complexity in the unittest code base. Agreed. Let's not add cruft to unittest. --

[issue12600] Support parameterized TestCases in unittest

R. David Murray added the comment: Note that this is fairly simple to do now via subclassing, so any proposed API would need to show a clear benefit over that approach to be worth the extra complexity in the unittest code base. -- ___ Python tracke

[issue12600] Support parameterized TestCases in unittest

Changes by Ezio Melotti : -- nosy: +Yaroslav.Halchenko, brian.curtin, eric.araujo, ericsnow, exarkun, ezio.melotti, fperez, michael.foord, nchauvat, ncoghlan, pitrou, r.david.murray versions: +Python 3.3 -Python 2.7, Python 3.2 ___ Python tracker

[issue12600] Support parameterized TestCases in unittest

New submission from Austin Bingham : In the discussion about adding support for parameterized tests (issue 7897), it seemed clear that parameterizing individual tests was a different issue from parameterizing TestCases. This, then, is a request to support parameterization of TestCases. The fu