[issue14534] Add method to mark unittest.TestCases as "do not run".

Changes by Wei Wu : Added file: http://bugs.python.org/file36315/01438f18ee18.diff ___ Python tracker ___ ___ Python-bugs-list mailing list Un

[issue14534] Add method to mark unittest.TestCases as "do not run".

Changes by Serhiy Storchaka : -- nosy: -serhiy.storchaka ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https

[issue14534] Add method to mark unittest.TestCases as "do not run".

Ezio Melotti added the comment: SGTM. The patch still needs docs and there are some comments on rietveld. The name of the decorator should be updated too, and possibly __unittest_base_class__ should be renamed to __unittest_abstract_class__ to match the name of the decorator. -- _

[issue14534] Add method to mark unittest.TestCases as "do not run".

Michael Foord added the comment: testBaseClass, abstractTestClass and abstractBaseClass are all fine with me. I wouldn't waste too much time bike-shedding it. If we need a decision let's go with abstractTestClass. -- ___ Python tracker

[issue14534] Add method to mark unittest.TestCases as "do not run".

Ezio Melotti added the comment: abstractTestClass/abstractBaseClass were up next in the list of names that I was considering, but they are not too explicit about the fact the the test case will get ignored/skipped (especially if one is not familiar iwth the concept and behavior of abstract cla

[issue14534] Add method to mark unittest.TestCases as "do not run".

Antoine Pitrou added the comment: "abstract_test_class" anyone? (or "abstractTestClass" if that looks more consistent) (not that I would need it myself!) -- ___ Python tracker _

[issue14534] Add method to mark unittest.TestCases as "do not run".

Changes by Martin Panter : -- nosy: +vadmium ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue14534] Add method to mark unittest.TestCases as "do not run".

Akira Li added the comment: About the name: abstract_tests could be used e.g.: @abstract_tests class AbcSetTests(TestCase): # test abc.Set Set = abstract_property() def setUp(self): self.set = self.Set('abc') def test_difference(self): self.asser

[issue14534] Add method to mark unittest.TestCases as "do not run".

Ezio Melotti added the comment: I left a few comments on rietveld. The patch should also include documentation. > Class decorator approach looks less obvious to me. [...] > But encountering the unittest.base_class decorator, I need to look in > the documentation and/or sources to understand how

[issue14534] Add method to mark unittest.TestCases as "do not run".

Victor Zhong added the comment: Hi Zach, I've pulled from the default branch. Please find attached the diff for "hg diff -r default Lib/unittest" in the attached "issue14534.v3.diff". Victor -- hgrepos: +266 Added file: http://bugs.python.org/file36086/issue14534.v3.diff

[issue14534] Add method to mark unittest.TestCases as "do not run".

Zachary Ware added the comment: Victor: Sorry for the delay in getting back to this. I'm attaching your full patch again; the diff you posted is a diff against your first patch, while what we need to be able to review it properly is a diff against the tip of the 'default' branch. You may be

[issue14534] Add method to mark unittest.TestCases as "do not run".

Victor Zhong added the comment: Hi Zach, I've pushed a fix here according to your suggestions: https://bitbucket.org/hllowrld/cpython/commits/fe10b98717a23fd914c91d42dcca383d53e924a8 Please also find attached the diff. -- hgrepos: +263 Added file: http://bugs.python.org/file35797/unnit

[issue14534] Add method to mark unittest.TestCases as "do not run".

Zachary Ware added the comment: Victor: I've left a review on Rietveld; it should have sent you an email with it. The basic change looks good to me, but there's some cleanup that will need to happen before it can be committed, and Michael will need to confirm that this does what he was expect

[issue14534] Add method to mark unittest.TestCases as "do not run".

Changes by Zachary Ware : -- stage: needs patch -> patch review ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue14534] Add method to mark unittest.TestCases as "do not run".

Zachary Ware added the comment: Attaching Victor and Lisha's patch in reviewable form. -- keywords: +patch Added file: http://bugs.python.org/file35792/issue14534.diff ___ Python tracker ___

[issue14534] Add method to mark unittest.TestCases as "do not run".

Victor Zhong added the comment: We made a patch for this issue at Bloomberg's Python Open Source Event. Please find the diff here: https://bitbucket.org/hllowrld/cpython/commits/382773b2611a86326568a22dd5cef6c7f7bae18c Zach Ware will review the patch. -- hgrepos: +262 nosy: +vzhong

[issue14534] Add method to mark unittest.TestCases as "do not run".

Ezio Melotti added the comment: +1 on the idea. While the mixin method works and it's not overly complex, it might not be immediately obvious to those unfamiliar with it and to those reviewing the code (i.e. there's no clear hint about the reason why the base class doesn't inherit from TestCa

[issue14534] Add method to mark unittest.TestCases as "do not run".

R. David Murray added the comment: Issue 19645 is an alternative way to solve the problem of calling methods on the mixin that "don't exist", and has other benefits. -- ___ Python tracker _

[issue14534] Add method to mark unittest.TestCases as "do not run".

Serhiy Storchaka added the comment: Note that we have to use mixin approach in the Python test suite to avoid discrepancies and merge conflicts between different versions. -- ___ Python tracker ___

[issue14534] Add method to mark unittest.TestCases as "do not run".

Kristján Valur Jónsson added the comment: Just want to restate my +1 for Michael's idea. I'm hit by this all the time and it is beautiful and expressive. It also does not preclude the annoying mix-in way of doing it. -- ___ Python tracker

[issue14534] Add method to mark unittest.TestCases as "do not run".

Michael Foord added the comment: To be honest, even though I understand it, I find the mixin pattern hard to read. You derive from object, but call methods (the assert methods for example) that don't exist in the class (or its inheritance chain). My experience, with even experienced Python dev

[issue14534] Add method to mark unittest.TestCases as "do not run".

Serhiy Storchaka added the comment: Class decorator approach looks less obvious to me. Looking at current standard mixing approach I understand what it do and why. But encountering the unittest.base_class decorator, I need to look in the documentation and/or sources to understand how it works.

[issue14534] Add method to mark unittest.TestCases as "do not run".

Michael Foord added the comment: Zachary: Inheriting from TestCase in your mixin is actually an anti-pattern. And yes, most people seem to do it (most people seem to misunderstand how to use mixins, which is why I like this approach of having a way of explicitly marking base classes). ---

[issue14534] Add method to mark unittest.TestCases as "do not run".

Michael Foord added the comment: My suggested solution is a class decorator you use on your base class that means "don't run tests from this class". @unittest.base_class class MyTestBase(TestCase): pass Not quite sure how that's sophisticated or confusing... Are you confusing the way it

[issue14534] Add method to mark unittest.TestCases as "do not run".

Serhiy Storchaka added the comment: Michael's suggestion looks too sophisticated and confusing to me. -- nosy: +serhiy.storchaka ___ Python tracker ___ __

[issue14534] Add method to mark unittest.TestCases as "do not run".

Zachary Ware added the comment: Right, but in my experience, it seems like a lot of people do inherit from TestCase in their mixin anyway, possibly just to have the TestCase methods available for auto-completion in their IDE. I've done the same, though I've remembered after writing the tests

[issue14534] Add method to mark unittest.TestCases as "do not run".

Michael Foord added the comment: If you're writing a mixin you don't need to derive from TestCase, you just derive from object. The point of this feature is to allow TestCase subclasses to be "base classes" instead of being used as a mixin. -- ___ P

[issue14534] Add method to mark unittest.TestCases as "do not run".

Zachary Ware added the comment: What if we simply rename the current unittest.TestCase class to unittest.BaseTestCase, and define unittest.TestCase as "class TestCase(BaseTestCase): pass"? Then mixin classes can derive from BaseTestCase and have all of the TestCase methods available (for auto

[issue14534] Add method to mark unittest.TestCases as "do not run".

R. David Murray added the comment: It's Michael's solution that is under consideration, and I guess no one has felt strongly enough about having it to write a patch. So this issue stays in limbo until someone does. -- ___ Python tracker

[issue14534] Add method to mark unittest.TestCases as "do not run".

Mark Lawrence added the comment: Do we have a consensus as to whether or not David's proposed solution is acceptable? -- nosy: +BreamoreBoy versions: +Python 3.5 -Python 3.3 ___ Python tracker

[issue14534] Add method to mark unittest.TestCases as "do not run".

Kristján Valur Jónsson added the comment: +1, we already have such decorators for individual test cases. Code should be obvious, particularly testing code and mixins often aren't. Magic such as identifying classes to run by their type should be over rideable. All magic should. -- nos

[issue14534] Add method to mark unittest.TestCases as "do not run".

Éric Araujo added the comment: FWIW I use the mixin approach too and find it simple and clean. I don’t have a problem with a method in the mixin class calling methods from TestCase. -- nosy: +eric.araujo ___ Python tracker

[issue14534] Add method to mark unittest.TestCases as "do not run".

R. David Murray added the comment: Note that I did just document the mixin idiom in the Lib/test docs. Which core developers probably don't read :) -- ___ Python tracker ___ _

[issue14534] Add method to mark unittest.TestCases as "do not run".

Antoine Pitrou added the comment: > So the technique I suggested is that the TestLoader checks classes for > the "testbase" (or whatever we call it) *in the class dict*. So > inheritance doesn't matter - a class is only excluded from test > loading if it has the attribute directly. Why not docu

[issue14534] Add method to mark unittest.TestCases as "do not run".

Michael Foord added the comment: Here are my objections to the standard (but not widely used outside our own tests) mixin pattern for base testcases (copied and pasted from issue 14408): Because you then have classes that inherit from object calling methods that clearly don't exist (until you

[issue14534] Add method to mark unittest.TestCases as "do not run".

Michael Foord added the comment: So the technique I suggested is that the TestLoader checks classes for the "testbase" (or whatever we call it) *in the class dict*. So inheritance doesn't matter - a class is only excluded from test loading if it has the attribute directly. -- __

[issue14534] Add method to mark unittest.TestCases as "do not run".

Antoine Pitrou added the comment: > Antoine: I've used the pattern you describe on a couple of occasions, > and it routinely confuses my code reviewers. Really? What is confusing about it? Perhaps we should simply document it. -- ___ Python tracker

[issue14534] Add method to mark unittest.TestCases as "do not run".

R. David Murray added the comment: Antoine: I don't have any problem with that personally, but Michael did, and he's the maintainer :) But there is a small advantage: it means you don't have to keep repeating the 'unittest.TestCase' boilerplate in each subclass declaration, you only have to

[issue14534] Add method to mark unittest.TestCases as "do not run".

Daniel Stutzbach added the comment: Wouldn't the subclass inherit the False value? Then the user would need to remember to override the value again in the subclass, which is error prone. Antoine: I've used the pattern you describe on a couple of occasions, and it routinely confuses my code r

[issue14534] Add method to mark unittest.TestCases as "do not run".

Antoine Pitrou added the comment: > A decorator would be provided that sets the attribute to False, since > that would make it visually obvious which TestCases are base classes > and not to be loaded. What's the point? Just derive from TestCase in the derived classes, not the base classes. -1

[issue14534] Add method to mark unittest.TestCases as "do not run".

New submission from R. David Murray : A common pattern in testing is to have a base test class that implements test methods, and subclasses that provide various data that drives the tests to be run in different ways. It is convenient for the base class to inherit from TestCase, but this cause