stryker-mutator / stryker-net

Mutation testing for .NET core and .NET framework!
https://stryker-mutator.io
Apache License 2.0
1.78k stars 184 forks source link

calculate mutation score only of changed lines of code in a file from pull requests #3077

Open shivambagadia23 opened 1 day ago

shivambagadia23 commented 1 day ago

Is your feature request related to a problem? Please describe. I wanted to use stryker in the pipeline such that when someone raises a new Pull Request stryker calculates mutation score of only the changed lines of code and not the entire file. By doing this, I want to enfore a restriction that if the mutation score of the changed lines in the PR is less than say 80% the build should fail. I tried baseline and since feature but both does not calculate mutation score based on only the changed lines instead it calculates mutation score for entire changed file which doesn't work in my case.

Describe the solution you'd like I would want a simple config that when passed in stryker-config or command line takes only the changed lines of code and returns the mutation score for the changed lines only.

Describe alternatives you've considered I have consideried using -m config and gave line span manually by giving -m filename.cs{line1..line2} but even this does not work for me. neither does the since or baseline feature works as they calculate mutation score for entire file chnaged.

Additional context Add any other context or screenshots about the feature request here.

dupdob commented 3 hours ago

Hi I have been thinking about this for the past few days and this raises several questions and remarks.

  1. I think you want to make sure PRs do not degrade the overall mutation score. Or maybe even you want them to improve the current score. Correct ?

  2. Bear in mind that the mutation score is related to the test base and not to rhe production code.

  3. When you talk about 'changed lines', are you referring to 'production code' lines ? Or 'test lines' or both ?

  4. If we compute the score only for the new/modifies mutants, you will not the expected guarantee: people could add and remove tests that so do not cover the modified lines. This would impact the overall score but not the marginal one.

  5. Conversely, focusing only on ´test lines' will result of changes in the production code' not impacting the marginal score.

  6. So Stryker needs to factor both. That's why it needs to retest every mutants that is covered by a changed test as well as any new or modified mutation.

As said earlier, filtering this result only for new or modified mutations would yield incorrect result.

That being said, the current logic still relies on a coarse granularity logic (file level). As such, we may look into on how to refine this granularity. We can get some line level diff level info, but this will remain more difficult to leverage for mutation coverage than it is for line coverage.