You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Right now the diff feature resets all the mutants when a test is changed.
Describe the solution you'd like
The current coverage analysis makes it possible to check which tests cover which mutants. I would extend this information by adding a property TestFilename to TestListDescription . This way we can check if the TestFilename equals one of the changed testfiles we using the GitDiffProvider. Whenever the tests are changed, the result status can than be reset to NotRun.
Describe alternatives you've considered
Ideally I would do like to check for a modified test which mutants it covers. This is however not a possibility because of the limitations of libgit2sharp. libgit2/libgit2sharp#1790 should fix this limitation. In the meanwhile however this is a good alternative
Stijn-Rutten
changed the title
Only tests mutant that are covered by changed test files
Only test mutants that are covered by changed test files
May 6, 2020
Is your feature request related to a problem? Please describe.
Right now the diff feature resets all the mutants when a test is changed.
Describe the solution you'd like
The current coverage analysis makes it possible to check which tests cover which mutants. I would extend this information by adding a property
TestFilename
toTestListDescription
. This way we can check if theTestFilename
equals one of the changed testfiles we using theGitDiffProvider
. Whenever the tests are changed, the result status can than be reset toNotRun
.Describe alternatives you've considered
Ideally I would do like to check for a modified test which mutants it covers. This is however not a possibility because of the limitations of libgit2sharp. libgit2/libgit2sharp#1790 should fix this limitation. In the meanwhile however this is a good alternative
Additional context
This feature relies on #1026
The text was updated successfully, but these errors were encountered: