Modify rule S5786: Migrate to LaYC format (#3181)

rules/S5786/java/rule.adoc

@@ -1,14 +1,38 @@
+JUnit5 test classes and methods should generally have package visibility.
+To fix this issue, change their visibility to the default package visibility.
+
 == Why is this an issue?
 
-JUnit5 is more tolerant regarding the visibilities of Test classes than JUnit4, which required everything to be ``++public++``.
+JUnit5 is more tolerant regarding the visibility of test classes and methods than JUnit4, which required everything to be `public`.
+Test classes and methods can have any visibility except `private`.
+It is however recommended to use the default package visibility to improve readability.
+
+[quote, JUnit5 User Guide]
+____
+Test classes, test methods, and lifecycle methods are not required to be `public`, but they must not be `private`.
+
+It is generally recommended to omit the public modifier for test classes, test methods, and lifecycle methods unless there is a technical reason for doing so – for example, when a test class is extended by a test class in another package.
+Another technical reason for making classes and methods public is to simplify testing on the module path when using the Java Module System.
+____
+
+=== What is the potential impact?
+
+The code will be non-conventional and readability can be slightly affected.
+
+=== Exceptions
+
+This rule does not raise an issue when the visibility is set to `private`, because `private` test methods and classes are systematically ignored by JUnit5, without a proper warning.
+In this case, there is also an impact on reliability and so it is handled by the rule https://rules.sonarsource.com/java/RSPEC-5810/[S5810].
 
+== How to fix it
 
-In this context, JUnit5 test classes can have any visibility but ``++private++``, however, it is recommended to use the default package visibility, which improves readability of code.
+You can simply change the visibility by removing the `public` or `protected` keywords.
 
+=== Code examples
 
-=== Noncompliant code example
+==== Noncompliant code example
 
-[source,java]
+[source,java,diff-id=1,diff-type=noncompliant]
 ----
 import org.junit.jupiter.api.Test;
 
@@ -21,9 +45,9 @@ public class MyClassTest { // Noncompliant - modifier can be removed
 ----
 
 
-=== Compliant solution
+==== Compliant solution
 
-[source,java]
+[source,java,diff-id=1,diff-type=compliant]
 ----
 import org.junit.jupiter.api.Test;
 
@@ -35,15 +59,11 @@ class MyClassTest {
 }
 ----
 
-
-=== Exceptions
-
-This rule does not raise an issue about ``++private++`` visibility, because ``++private++`` test methods and classes are systematically ignored by JUnit5, without a proper warning. It's not a ``++Code Smell++`` but a ``++Bug++`` handled by the rule S5810 .
-
-
 == Resources
 
-* https://junit.org/junit5/docs/current/user-guide/#writing-tests-classes-and-methods[JUnit 5 Test Classes and Methods]
+=== Documentation
+
+* https://junit.org/junit5/docs/current/user-guide/#writing-tests-classes-and-methods[JUnit5 User Guide: Test Classes and Methods]
 
 ifdef::env-github,rspecator-view[]