Should the `abstractmethod` be removed by mutmut?
See original GitHub issueI’ve got this class as part of a mypy exercise:
@runtime_checkable
class Invertible(Protocol[KeyType, ValueType]):
@abstractmethod
def __inverse__(self) -> "Invertible[ValueType, KeyType]":
return NotImplemented
mutmut run
removed the @abstractmethod
annotation, and that mutation survived. How would I construct a test which kills this mutant? It looks like the only side effect of this annotation is to set a __isabstractmethod__ = True
property on the function; I don’t know whether that has any further side effects.
Alternatively, is the issue that I shouldn’t annotate this function at all?
If this is a genuine false positive, should mutmut
be changed to not delete this specific annotation?
Issue Analytics
- State:
- Created 2 years ago
- Comments:7 (2 by maintainers)
Top Results From Across the Web
how can i test an abstract method in python 2.6 - Stack Overflow
these two properties are covered when i try to instantiate the class, but i need test the abstract methods (add and remove) for...
Read more >Ignore ABC abstract methods · Issue #1131 · nedbat/coveragepy
Coverage should ignore abstract methods by default and should not require ... Once you do that, the entire abstract method is excluded from ......
Read more >abc — Abstract Base Classes — Python 3.11.1 documentation
The abstractmethod() only affects subclasses derived using regular inheritance; “virtual subclasses” registered with the ABC's register() method are not ...
Read more >mutmut Documentation
Mutmut is a mutation testing system for Python, with a strong focus on ease of use. If you don't know what mutation.
Read more >Abstract Methods and Classes (The Java™ Tutorials ...
An abstract method is a method that is declared without an implementation (without ... If a class includes abstract methods, then the class...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Maybe not as much value as with other method decorators, but at least if all the
@abstractmethod
decorators are removed a user of your code can run into problems. He could instantiate the base class without errors, and only run into errors when he hits one of the methods that is not implemented in the base class. Even if only one of the decorators is removed, someone who is creating a subclass might forget to implement that specific method which might cause bugs that are not noticed immediately.I’d say the value of killing the mutant is the same as using the
@abstractmethod
decorator in the first place. If I use it, I do so on purpose - I want the user to be notified as soon as possible that this class is not intended for direct use, and that this method must be overwritten for a subclass to work as intended.The
@abstractmethod
decorator declares that this method has to be overwritten/implemented by a subclass. You will not be able to instantiate an abstract base class at runtime.I would say that
mutmut
is correct about testing if removing the decorator has an effect. If you use an@abstractmethod
, you want that class to not be used directly. Thus you should add a test like this:What
mutmut
can potentially detect here is if you forgot to inherit fromabc.ABC
. (However, if you have multiple abstract methods,mutmut
should probably perform a mutation where all the instances of@abstractmethod
are removed to reliably detect this).