rspec/rules/S3415/java/rule.adoc

The standard assertions library methods such as <code>org.junit.Assert.assertEquals</code>, and <code>org.junit.Assert.assertSame</code> expect the first argument to be the expected value and the second argument to be the actual value. For AssertJ, it's the other way around, the argument of <code>org.assertj.core.api.Assertions.assertThat</code> is the actual value, and the subsequent calls contain the expected values. Swap them, and your test will still have the same outcome (succeed/fail when it should) but the error messages will be confusing. 

This rule raises an issue when the actual argument to an assertions library method is a hard-coded value and the expected argument is not.

Supported frameworks:

* JUnit4
* JUnit5
* https://assertj.github.io/doc/[AssertJ]

== Noncompliant Code Example

----
org.junit.Assert.assertEquals(runner.exitCode(), 0, "Unexpected exit code");  // Noncompliant; Yields error message like: Expected:<-1>. Actual:<0>.
org.assertj.core.api.Assertions.assertThat(0).isEqualTo(runner.exitCode()); // Noncompliant
----

== Compliant Solution

----
org.junit.Assert.assertEquals(0, runner.exitCode(), "Unexpected exit code");
org.assertj.core.api.Assertions.assertThat(runner.exitCode()).isEqualTo(0);
----