Create rule S7177: @DirtiesContext should be properly configured

rules/S7177/java/metadata.json

@@ -1,5 +1,5 @@
 {
-  "title": "FIXME",
+  "title": "@DirtiesContext should be properly configured",
   "type": "CODE_SMELL",
   "status": "ready",
   "remediation": {
@@ -11,15 +11,13 @@
   "defaultSeverity": "Major",
   "ruleSpecification": "RSPEC-7177",
   "sqKey": "S7177",
-  "scope": "All",
+  "scope": "Tests",
   "defaultQualityProfiles": ["Sonar way"],
   "quickfix": "unknown",
   "code": {
     "impacts": {
-      "MAINTAINABILITY": "HIGH",
-      "RELIABILITY": "MEDIUM",
-      "SECURITY": "LOW"
+      "RELIABILITY": "MEDIUM"
     },
-    "attribute": "CONVENTIONAL"
+    "attribute": "LOGICAL"
   }
 }

rules/S7177/java/rule.adoc

@@ -1,44 +1,46 @@
-FIXME: add a description
-
-// If you want to factorize the description uncomment the following line and create the file.
-//include::../description.adoc[]
+The `@DirtiesContext` annotation marks the ApplicationContext as dirty and indicates that it should be cleared and recreated. 
+This is important in tests that modify the context, such as altering the state of singleton beans or databases. 
+However, improper use of the test phase configurations (such as `classMode` or `methodMode`) can lead to redundant or unnecessary context reloads, 
+potentially impacting performance or leading to incorrect test behavior.
 
 == Why is this an issue?
 
-FIXME: remove the unused optional headers (that are commented out)
+Misusing `@DirtiesContext` by selecting incorrect `classMode` and `methodMode` values can result in unnecessary context reloads. 
+For example, using `BEFORE_EACH_TEST_METHOD` at the class level along with `AFTER_METHOD` at the method level can result in the context being reloaded 
+multiple times unnecessarily. This redundancy wastes resources, increases test execution time, and could lead to unexpected test failures.
 
-//=== What is the potential impact?
+Also, configuring the `methodMode` at the class level or the `classMode` at the method level does not have meaning and will not have the expected behavior.
 
 == How to fix it
-//== How to fix it in FRAMEWORK NAME
 
 === Code examples
 
 ==== Noncompliant code example
 
 [source,java,diff-id=1,diff-type=noncompliant]
 ----
-FIXME
+@ContextConfiguration
+@DirtiesContext(methodMode = MethodMode.AFTER_METHOD) // Noncompliant, for class-level control, use classMode instead.
+public class TestClass {
+  @DirtiesContext(classMode = DirtiesContext.ClassMode.AFTER_CLASS) // Noncompliant, for method-level control use methodMode instead
+  public void test() {...}
+}
 ----
 
 ==== Compliant solution
 
 [source,java,diff-id=1,diff-type=compliant]
 ----
-FIXME
+@ContextConfiguration
+@DirtiesContext(classMode = DirtiesContext.ClassMode.AFTER_CLASS) // Noncompliant, for class-level control, use classMode instead.
+public class TestClass {
+  @DirtiesContext(methodMode = MethodMode.AFTER_METHOD) // Noncompliant, for method-level control use methodMode instead
+  public void test() {...}
+}
 ----
 
-//=== How does this work?
-
-//=== Pitfalls
-
-//=== Going the extra mile
+== Resources
 
+=== Documentation
 
-//== Resources
-//=== Documentation
-//=== Articles & blog posts
-//=== Conference presentations
-//=== Standards
-//=== External coding guidelines
-//=== Benchmarks
+* Spring documentation - https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/test/annotation/DirtiesContext.html[@DirtiesContext]