Markus Schirp
Markus Schirp
> The ability to classify the mutations for me helped me envision additional ones. SO I felt more engaged in the process of considering what makes a valuable mutation, as...
> I would add that classifying the mutations allowed me to develop mitigation strategies in my code. It helped me develop a mental cheat sheet of how to code to...
I support the introduction of such a taxonomy. But I do no see me doing it. For my personal mutant experience there are more pressing issues to address. And my...
> This is probably OT but one of the time-wasters I find is when I discover a sequence of unkilled mutations that are BIZARRELY and obviously NON-EXECUTABLE which eventually I...
> I spoke elsewhere of the friction to mutation testing, and things such as the above (requiring experience to deduce the action to take, and to recognize patterns quickly), are...
@tjchambers Even when I'd write a tool for another languages, the decisions will be the same: My needs first, than client, than everyone else - So we can keep on...
@backus I outlined a strategy to attach more metadata to mutations in channel multiple times, and we already have similar issues, like https://github.com/mbj/mutant/issues/395. I'm willing to refactor mutants internals alongside...
@dgollahon that specific crash is solved with `unparser-0.6.5` and these crashes are "rare" in sense of: They are 'serious bugs' in the ecosystem. I agree they should be easier to...
> But I dont want to change my tests in **any** way just to be able to see my Mutation coverage. Thats an odd constraint, where does it come from,...
@pawelpacana While I support this initiative, I wounder if in `rails_event_store` you'll end up in actually defining a global config file, since mutant now (since `v0.10.24` that was just released)...