I wonder if this would also be useful with mutation testing, to filter out mutants that don't change the behavior of the code. These are the bane of mutation testing, as they cannot be killed by tests.
I was asking what about what are the categories such mutations fall under. An example listed is `if (false) { … }` and generating mutants for the interior code block. The paper lists some although it looks like often it’s language/implementation specific. I’m curious how many such mutants trip up cargo-mutants.
(2022)
Previously: https://news.ycombinator.com/item?id=31832588
I wonder if this would also be useful with mutation testing, to filter out mutants that don't change the behavior of the code. These are the bane of mutation testing, as they cannot be killed by tests.
Can you give an example of a mutation test that can’t be killed by a test? Are you saying something like Math.abs(variable)?
A mutant that doesn't change the behavior of the program by definition cannot be killed by a test. I mean, how do you imagine a test could do that?
I'm asking how does a mutant not change the behavior of the program?
By not changing the behavior? What makes you think every mutant must change the behavior?
Here's a paper on these so-called equivalent mutants "in the wild", in Java programs, and their detection: https://dl.acm.org/doi/pdf/10.1145/3650212.3680310
I was asking what about what are the categories such mutations fall under. An example listed is `if (false) { … }` and generating mutants for the interior code block. The paper lists some although it looks like often it’s language/implementation specific. I’m curious how many such mutants trip up cargo-mutants.