Add doppelganger test to all analyzers #75
Labels
Comments
rjmurillo
pushed a commit
that referenced
this issue
Jun 10, 2024
…lysis.Testing patterns (#76) After the switch to using `Microsoft.CodeAnalysis.Testing`, refactor the tests to better follow the test infrastructure conventions. (For additional examples, check out the dotnet/roslyn-analyzers repo). 1. Use helper classes instead of inheritance to make the tests more flexible 2. Centralize test defaults in a new `Test` class rather than in a base class 3. Add a set of global usings to the default test to simplify tests and make test authoring easier 4. Use xUnit's data-driven test method to simplify test scenarios - Allows for a matrix of tests, both in the global namespace (fixes #56) and in a given namespace - Makes test debugging a bit easier as there's only a single Moq call asserted in each test - Makes reasoning about the test a bit more difficult, as now there's distance between the test clause and the setup 5. After the test refactoring, there were a few cases of clear duplication; removed and verified code coverage numbers are the same I tried to also create "doppelganger" tests in this PR, like in `NoConstructorArgumentsForInterfaceMockAnalyzerTests` where a user creates a `Mock<T>` class in the namespace to make sure the analyzers are doing fully-qualified name resolution. However, to do that generically requires duplicating a lot of more of Moq's own API, and I'm not sure if that's a good idea, so filed #75 to track. There's probably more that can be done to DRY out the test templates, but I wanted to make sure this was a good step forward before going any further.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
NoConstructorArgumentsForInterfaceMockAnalyzerTestshas a doppleganger test to ensure that it doesn't flag a user's class that happens to also be namedMock<T>. We should:The text was updated successfully, but these errors were encountered: