search

mbj / mutant

Automated code reviews via mutation testing - semantic code coverage.
Other
1.96k stars 153 forks source link

Separate mutants into high level mutants and first order mutants. #250

Open kbrock opened 10 years ago

kbrock commented 10 years ago

This is spun off of #248

Refactor mutant engine to have high order mutants and first order mutants. Only run first order mutants if hight level mutants do not fail.

Example:

A high order mutant would be replacing a method body with a no-op. If this fails, do not run first-order mutants that modify code within the method.

dgollahon commented 4 years ago

I think this is our issue for tracking "dependent mutations" so I am leaving a note that we should also consider no-op mutations here as discussed in this comment when this is implemented (or spawn an additional issue).

mbj commented 4 years ago

@dgollahon Noops should be run next to their siblings to increase the chance isolation issues on concurrency can be found.

But a failed noop needs to make pending evils on the same subject not eligible anymore. I've got such a scheduler in a private mutant fork. And it IMO falls into the same category.

This is territory I do not want to implement in Ruby again, and possibly has to go to the external (and generic) manager process I'm preparing in Haskell.

dgollahon commented 4 years ago

Sure, that's fine. I just wanted to make sure this behavior was tracked in an open issue somewhere.