## 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 instead, the argument of `org.assertj.core.api.Assertions.assertThat` is the actual value, and the subsequent calls contain the expected values.

### What is the potential impact?

Having the expected value and the actual value in the wrong order will not alter the outcome of tests, (succeed/fail when it should) but the error messages will contain misleading information.

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.

## How to fix it

You should provide the assertion methods with a hard-coded value as the expected value, while the actual value of the assertion should derive from the portion of code that you want to test.

Supported frameworks:

- JUnit4
- JUnit5
- AssertJ

### Code examples

#### 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);