New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add assertIsSubclass
and assertNotIsSubclass
to unittest.TestCase
#59024
Comments
The attached patch adds two helper methods to These methods can be used like: These new methods provide a nicer error message and more consistent interface over the alternatives: |
Hi, this has been discussed already, and we took the decision to leave these out, since checking for subclasses is not as common as checking the type. |
I can't find a previous discussion of this topic. If you know the list it happened on, or the bug#, let me know as I'd be curious to see the discussion. While I could concede that checking type is arguably a more common case than checking ancestry, I think that checks like assertIsSubclass have a lot of value. First, if you view your collection of unit tests as pools of change detectors, this type of check is very valuable in order to detect changes in ancestry that result from a refactoring. Second, if you use a test-driven style of development, this is a very convenient method to have as your tests and code evolve, because the amount of code you have to write to create a failing test becomes a one-liner. As an aside, I *would* like to see the submitted patch provide more detail upon failure. Namely, if X is not a subclass of Y, it would be nice to know what it *is* a subclass of in the resulting output. |
I couldn't find any pointer to the discussion (maybe it happened on IRC), but the general goal is to provide only the most used/important assert methods and avoid bloating the API with less common ones. |
I agree that testing for subclass is a rather specialized thing, and thus should be defined by a project that needs it. Normal API-centric unit tests shouldn't, IMO, care whether X is a subclass of Y. If you are using it to write a failing unit test to "drive" refactoring from one class to another, that is, I think, a very good example of a specialized use case (one I would certainly never use, for example) and you should just put it in your own project test codebase. |
assertIsSubclass
andassertNotIsSubclass
tounittest.TestCase
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: