Why is this an issue?
The standard assertions library methods such as org.junit.Assert.assertEquals, and org.junit.Assert.assertSame 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
org.assertj.core.api.Assertions.assertThat 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:
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);
