Enhance mutation testing documentation with new sections #50594
Conversation
Added sections on interpreting mutation testing results, integrating Stryker.NET into CI/CD workflows, and customization options for mutation testing configurations.
dotnet-policy-service
bot
added
dotnet-fundamentals/svc
community-contribution
There was a problem hiding this comment.
Pull request overview
This PR enhances the mutation testing documentation by adding three new sections that provide practical guidance for developers. The additions help users understand how to interpret mutation testing results, integrate Stryker.NET into CI/CD pipelines, and customize mutation testing configurations for their specific needs.
- Adds guidance on interpreting mutation testing results (killed, survived, and timeout mutants)
- Introduces CI/CD integration information with threshold configuration examples
- Provides customization options through stryker-config.json file examples
Co-authored-by: Copilot <[email protected]>
Co-authored-by: Copilot <[email protected]>
Co-authored-by: Copilot <[email protected]>
|
@copilot open a new pull request to apply changes based on the comments in this thread |
|
@Youssef1313 @Evangelink PTAL. |
Added information about customization options in Stryker.NET. Added a blank line as linter asked
| ## Adding mutation testing to your CI/CD workflow | ||
|
|
||
| You can seamlessly integrate mutation testing into your continuous integration and delivery workflows. For instance, Stryker.NET can be configured to run within your Azure Pipelines or GitHub Actions setup, allowing you to enforce quality thresholds as part of your automated testing process. |
There was a problem hiding this comment.
The phrase "can be configured" is passive voice. According to the Markdown writing style guidelines, use active voice. Consider rephrasing to "You can configure Stryker.NET to run within your Azure Pipelines or GitHub Actions setup" or "Configure Stryker.NET to run within your Azure Pipelines or GitHub Actions setup".
| - **Killed**: These are changes that your tests successfully caught. A high number of killed mutants indicates that your test suite effectively detects logic errors. | ||
|
|
||
| - **Survived**: These changes weren't caught by your tests. Review them to identify gaps in test coverage or assertions that are too weak. Focus on adding targeted unit tests that would fail if the mutant were real. |
There was a problem hiding this comment.
According to the Markdown writing style guidelines, lists should use complete sentences with proper punctuation. The list items on lines 117-121 are complete sentences but only the last item has a period. Add periods to the end of lines 117 and 119 for consistency.
| ], | ||
| "ignore-methods": [ | ||
| "*Logs" | ||
| ] |
There was a problem hiding this comment.
The JSON configuration is missing a comma after the closing bracket of the "ignore-methods" array. This will cause a JSON parsing error. Add a comma after line 155 before "mutate".
| ] | |
| ], |
| ``` | ||
|
|
||
| - **ignore-mutations**: These are the methods or expressions that you want to ignore because they are noisy, or you consider not needed based on your application logic needs. They will show up in your reports as `Ignored`. | ||
| - **ignore-methods**: You can use this to skip entire methods based on their signatures. Also, those will appear in your reports as Ignored. In our example, we ignore all methods ending in "Logs". |
There was a problem hiding this comment.
The description list items should use consistent punctuation. Since these are complete sentences, add a period at the end of line 164 to match the style of line 165.
| ``` | ||
|
|
||
| - **ignore-mutations**: These are the methods or expressions that you want to ignore because they are noisy, or you consider not needed based on your application logic needs. They will show up in your reports as `Ignored`. | ||
| - **ignore-methods**: You can use this to skip entire methods based on their signatures. Also, those will appear in your reports as Ignored. In our example, we ignore all methods ending in "Logs". |
There was a problem hiding this comment.
This sentence has a grammatical error and doesn't follow the guideline to use simple, concise language. Consider rephrasing to: "Also, these appear in your reports as Ignored." or better yet, "These also appear in your reports as Ignored." using active voice.
| ], | ||
| "ignore-methods": [ | ||
| "*Logs" | ||
| ] |
There was a problem hiding this comment.
The JSON configuration is missing a comma after the closing bracket of the "ignore-mutations" array. This will cause a JSON parsing error. Add a comma after line 152 before "ignore-methods".
| ] | |
| ], |
| } | ||
| ``` | ||
|
|
||
| - **ignore-mutations**: These are the methods or expressions that you want to ignore because they are noisy, or you consider not needed based on your application logic needs. They will show up in your reports as `Ignored`. |
There was a problem hiding this comment.
The phrase "or you consider not needed" is grammatically incorrect. Change it to "or you consider them not needed" or better yet, simplify to "or aren't needed" to follow the guideline of using contractions and simpler language.
|
|
||
| - **ignore-mutations**: These are the methods or expressions that you want to ignore because they are noisy, or you consider not needed based on your application logic needs. They will show up in your reports as `Ignored`. | ||
| - **ignore-methods**: You can use this to skip entire methods based on their signatures. Also, those will appear in your reports as Ignored. In our example, we ignore all methods ending in "Logs". | ||
| - **mutate**: Without this option, Stryker will try to mutate all the files in your project. With this, you can ignore files or entire folders. In the example above, we ignore everything inside a _Migrations_ folder and all _.Designer.cs_ files (which are usually autogenerated) . |
There was a problem hiding this comment.
There's an extra space before the closing parenthesis. Remove the space before the period in "(which are usually autogenerated) ." to make it "(which are usually autogenerated)."
| - **mutate**: Without this option, Stryker will try to mutate all the files in your project. With this, you can ignore files or entire folders. In the example above, we ignore everything inside a _Migrations_ folder and all _.Designer.cs_ files (which are usually autogenerated) . | |
| - **mutate**: Without this option, Stryker will try to mutate all the files in your project. With this, you can ignore files or entire folders. In the example above, we ignore everything inside a _Migrations_ folder and all _.Designer.cs_ files (which are usually autogenerated). |
|
|
||
| ## Customization | ||
|
|
||
| Besides setting thresholds for your pipeline, Stryker.NET offers the possibility of having different configurations for each of your project needs. You can do this customization of behavior using the _stryker-config.json_ file. |
There was a problem hiding this comment.
The phrase "offers the possibility of having different configurations" is unnecessarily wordy. Following the guideline to use simpler, more direct language, rephrase to "supports different configurations" or "allows different configurations".
|
|
||
| ## Customization | ||
|
|
||
| Besides setting thresholds for your pipeline, Stryker.NET offers the possibility of having different configurations for each of your project needs. You can do this customization of behavior using the _stryker-config.json_ file. |
There was a problem hiding this comment.
The file reference "stryker-config.json" should use code formatting according to the .NET documentation guidelines. Change "stryker-config.json" to "stryker-config.json" for proper file name formatting.
2 participants
Added sections on interpreting mutation testing results, integrating Stryker.NET into CI/CD workflows, and customization options for mutation testing configurations.
Internal previews