Why is this an issue?
The standard assertions library methods such as AreEqual and AreSame in MSTest and
NUnit, or Equal and Same in XUnit, expect the first argument to be the expected value and
the second argument to be the actual value. 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 second argument to an assertions library method is a hard-coded value and the first argument is not.
Noncompliant code example
Assert.AreEqual(runner.ExitCode, 0, "Unexpected exit code"); // Noncompliant; Yields error message like: Expected:<-1>. Actual:<0>.
Compliant solution
Assert.AreEqual(0, runner.ExitCode, "Unexpected exit code");
