feat(MutateArgument): Allow the user to specify which files to mutate.

[anhaehne]

I created a new IMutantFilter that allow to specify which files should be in- or excluded as described in #322.

The files-to-excluded parameter is now marked as deprecated but the changes should be fully backwards compatible. If files-to-excluded is specified their paths will be converted to exclude file patterns in the StrykerOptions.

New configuration section:

Mutate

To specify which files should be mutated you can use file pattern to in- or excluded files or even only parts of a files. By default all files are included.

dotnet stryker --mutate "['C:/Repos/MyProject/MyFile.cs']"
dotnet stryker -m "['C:/Repos/MyProject/MyFile.cs']"

The patterns support globbing syntax to allow wildcards.

dotnet stryker --mutate "['**/*Services.cs']"
dotnet stryker -m "['**/*Services.cs']"

You can add an ! in front of the pattern to exclude all files that match the pattern.

dotnet stryker --mutate "['!**/*Factory.cs']"
dotnet stryker -m "['!**/*Factory.cs']"

When only exclude patterns are provided, all files will be included that do not match any exclude pattern. If both, include and exclude patterns, are provided, only the files that match an include pattern but not also an exclude pattern will be included. The order of the patterns is irrelevant.

Example:

Patterns	File	Will be mutated
[]	MyFolder/MyFactory.cs	Yes
[]	MyFolder/MyService.cs	Yes
['**/*.*']	MyFolder/MyFactory.cs	Yes
['**/*.*']	MyFolder/MyService.cs	Yes
['!**/MyFactory.cs']	MyFolder/MyFactory.cs	No
['!**/MyFactory.cs']	MyFolder/MyService.cs	Yes
['!**/MyFactory.cs', '**/My*.cs']	MyFolder/MyFactory.cs	No
['!**/MyFactory.cs', '**/My*.cs']	MyFolder/MyService.cs	Yes

To allow more fine grained filtering you can also specify the span of text that should be in- or excluded. A span is defined by the indices of the first character and the last character.

dotnet stryker --mutate "['MyFolder/MyService.cs{10..100}']"
dotnet stryker -m "['MyFolder/MyService.cs{10..100}']"

[rouke-broersma]

@anhaehne The problem is this:

You're not normalizing the filePattern, so it will never accurately match.

@richardwerkman I'm feeling like our decision to normalize all filepaths to the current filesystem is maybe the wrong choice. Perhaps we should agree on one style of filepaths to be used internally by stryker (including in filters and such) and then only normalize to the current filesystem filepaths when we're interacting with the filesystem. Then in the rest of stryker we can be sure what filepaths should look like, and always convert to "StrykerInternalPathSeperator" or something.

[anhaehne]

So should we just normalize all paths to forwardslash ('/') since both windows and *nix understand those?

[rouke-broersma]

So should we just normalize all paths to forwardslash ('/') since both windows and *nix understand those?

If that works, I am okay with that solution. How about you @richardwerkman ?

It does mean we need to normalize every single path or path filter going in and out of stryker. We may be missing some cases right now that accidentally work fine but might break if we change how we normalize.

[anhaehne]

I've looked at the code of System.IO.Path and microsoft seems to just replace all forward and backward slashes with backward slashes on windows [1].

On unix it's just forwards slashes since backwards slashes are not allowed anyways. [2].

When normalizing we should probably just replace both with Path.DirectorySeparatorChar so we can still use methods like Path.Combine without the need to normalize the result every time.

So path.Replace(Path.AltDirectorySeparatorChar, Path.DirectorySeparatorChar) should work for every platform.

[rouke-broersma]

I've looked at the code of System.IO.Path and microsoft seems to just replace all forward and backward slashes with backward slashes on windows [1].

On unix it's just forwards slashes since backwards slashes are not allowed anyways. [2].

When normalizing we should probably just replace both with Path.DirectorySeparatorChar so we can still use methods like Path.Combine without the need to normalize the result every time.

So path.Replace(Path.AltDirectorySeparatorChar, Path.DirectorySeparatorChar) should work for every platform.

Ah I did not realize Path.AltDirectorySeparatorChar was / on windows. That is almost what we do already in FilePathUtils.Convert but it would be would be more clean to use AltDirectorySeparatorChar.

[anhaehne]

Ok i found the reason one integration test did work locally on my machine. I renamed a file but only changed the casing, which git obviously didn't care about. 😄 So if there are no more change request we can complete this PR.

[rouke-broersma]

Awesome! 👍 Will take a look as soon as I have time.

[rouke-broersma]

@anhaehne While testing locally on a full framework project from my company stryker crashed in an unexpected way while mutating. The latest released version of stryker does not have this problem. I'm currently investigating whether the problem is with this PR or with master.

[anhaehne]

If you got a log or a way to reproduce it, let me know.

[rouke-broersma]

The issue seems to be with master, but since I can't validate whether this change works on my internal project I'm not gonna merge it until we fix master. I don't see any changes neccesary in the PR at this time though so it should get merged after.

[rouke-broersma]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).