sixty-north
More mutation operators
We obviously need more operations. This task really is "make a list of operators and make issues for creating them."
- Bitbucket: https://bitbucket.org/austin_bingham/cosmic-ray/issue/11
- Originally reported by: austin_bingham
- Originally created at: 2015-02-04T13:03:15.254
Here's the list from MutPy:
- AOD - arithmetic operator deletion
- AOR - arithmetic operator replacement
- ASR - assignment operator replacement
- BCR - break continue replacement
- COD - conditional operator deletion
- COI - conditional operator insertion
- CRP - constant replacement
- DDL - decorator deletion
- EHD - exception handler deletion
- EXS - exception swallowing
- IHD - hiding variable deletion
- IOD - overriding method deletion
- IOP - overridden method calling position change
- LCR - logical connector replacement
- LOD - logical operator deletion
- LOR - logical operator replacement
- ROR - relational operator replacement
- SCD - super calling deletion
- SCI - super calling insert
- SIR - slice index remove
Experimental mutation operators:
- CDI - classmethod decorator insertion
- OIL - one iteration loop
- RIL - reverse iteration loop
- SDI - staticmethod decorator insertion
- SDL - statement deletion
- SVD - self variable deletion
- ZIL - zero iteration loop
Original comment by: austin_bingham
I think that the MutPy list is implemented, except for less worthy mutators. Some of the experimental already implemented as part of pylint. Think its time to create another list:)
I think that the MutPy list is implemented, except for less worthy mutators.
I'm not sure which operators are more or less "worthy" :) But there are definitely a number of MutPy operators I'd like to investigate/implement, e.g. slice index remove, super calling deletion/insert.
Some of the experimental already implemented as part of pylint.
Even if pylint helps detect certain problems, I think we should still give CR support for performing related mutations. Users might not be using pylint. But I definitely consider these operators to be lower priority.
One of the major issues to address with the mutation is whether false positive is something that should be fine within the package boundaries and if so, how does the package handle it to be blacklabeled or any other mechanism to prevent it
One of the major issues to address with the mutation is whether false positive is something that should be fine within the package boundaries
This is definitely a major issue. We have to deal with the issue of "false equivalents" where mutations are practically undetectable. At the same time we have to deal with situations where the user doesn't want to - or for some reason can't - create tests to deal with a surviving mutant. It's a big topic in mutation testing in general, and something I've given a fair amount of thought to.
how does the package handle it to be blacklabeled or any other mechanism to prevent it
My plan for dealing with is much as you describe: allow the user to specify that certain mutations should not be performed at certain locations, i.e. to "blacklist" mutations for certain parts of code. The discussion of this topic should take place in #97, where you'll see that there's even an exploratory branch for this work. If you have ideas or want to help out, that would be great!