51369b610e
When an include is not surrounded by empty lines, its content is inlined on the same line as the adjacent content. That can lead to broken tags and other display issues. This PR fixes all such includes and introduces a validation step that forbids introducing the same problem again.
72 lines
3.2 KiB
Plaintext
72 lines
3.2 KiB
Plaintext
== Why is this an issue?
|
|
|
|
To ensure proper testing, it is important to include test cases in a test class. If a test class does not have any test cases, it can give the wrong impression that the class being tested has been thoroughly tested, when in reality, it has not.
|
|
|
|
This rule will raise an issue when any of these conditions are met:
|
|
|
|
* For `NUnit`, a class is marked with `TestFixture` but does not contain any method marked with `Test`, `TestCase`, `TestCaseSource`, or `Theory`.
|
|
* For `MSTest`, a class is marked with `TestClass` but does not contain any method marked with `TestMethod` or `DataTestMethod`.
|
|
|
|
It does not apply to `xUnit` since `xUnit` does not require a https://xunit.net/docs/comparisons#attributes[test class attribute].
|
|
|
|
=== Exceptions
|
|
|
|
There are scenarios where not having any test cases within a test class is perfectly acceptable and not seen as a problem.
|
|
|
|
==== Abstract classes
|
|
|
|
To facilitate the creation of common test cases, test logic, or test infrastructure, it is advisable to use a base class.
|
|
|
|
Additionally, in both `NUnit` and `MSTest`, abstract classes that are annotated with their respective attributes (`TestFixture` in NUnit and `TestClass` in MSTest) are automatically ignored.
|
|
|
|
Therefore, there is no need to raise an issue in this particular scenario.
|
|
|
|
More information here:
|
|
|
|
* https://docs.nunit.org/articles/nunit/writing-tests/attributes/testfixture.html[`TestFixture` documentation in `NUnit`]
|
|
* https://github.com/microsoft/testfx/blob/0f19160cc319338ef6e23acb320da1562b40decd/src/Adapter/MSTest.TestAdapter/Discovery/TypeValidator.cs#L86-L97[`TypeValidator` class in `MSTest` (GitHub)]
|
|
|
|
==== Derived classes that inherit test cases from a base class
|
|
|
|
A base class containing one or more test cases to provide generic test cases is also considered a compliant scenario.
|
|
|
|
==== Classes that contain `AssemblyInitialize` or `AssemblyCleanup` methods
|
|
|
|
*This particular exception scenario only applies to the MSTest test framework.*
|
|
|
|
The `AssemblyInitialize` and `AssemblyCleanup` attributes are used to annotate methods that are executed only once at the beginning and at the end of a test run. These attributes can only be applied once per assembly.
|
|
|
|
It is logical to have a dedicated class for these methods, and this scenario is also considered compliant.
|
|
|
|
Furthermore, it is important to note that the test engine will execute a method annotated with either the `AssemblyInitialize` or `AssemblyCleanup` attribute only if that method is part of a class annotated with the `TestClass` attribute.
|
|
|
|
More information here:
|
|
|
|
* https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2008/ms245278(v=vs.90)[`AssemblyInitialize` attribute]
|
|
* https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2008/ms245265(v=vs.90)[`AssemblyCleanup` attribute]
|
|
|
|
include::how-mstest.adoc[]
|
|
|
|
include::how-nunit.adoc[]
|
|
|
|
include::resources.adoc[]
|
|
|
|
ifdef::env-github,rspecator-view[]
|
|
|
|
'''
|
|
== Implementation Specification
|
|
(visible only on this page)
|
|
|
|
include::../message.adoc[]
|
|
|
|
'''
|
|
== Comments And Links
|
|
(visible only on this page)
|
|
|
|
=== on 9 Aug 2017, 12:11:08 Amaury Levé wrote:
|
|
Please review
|
|
|
|
include::../comments-and-links.adoc[]
|
|
|
|
endif::env-github,rspecator-view[]
|