• Home
• org.sonarsource.dotnet
• sonar-csharp-plugin
• 9.32.0.97167
• source code
• S3415.html

×

Project download

Many resources are needed to download a project. Please understand that we have to compensate our server costs. Thank you in advance.
Project price only 1 $

You can buy this project and download/modify it how often you want.

org.sonar.plugins.csharp.S3415.html Maven / Gradle / Ivy

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.
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.
Code examples
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");