| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Fixed issues: - AZ6nl5xRqzNTKShd3hv1 for java:S3415 rule Generated by SonarQube Agent (task: fb8437fe-faca-4ed6-8d4e-cd07f854132e)
| Back | FazBrowse Home | New Git URL |
Fixed a SonarQube issue by swapping the arguments of an assertNotEquals call to follow the correct convention of (expected, actual). This ensures that assertion failure messages will be clear and meaningful, with the expected value appearing first as intended.
View Project in SonarCloud
Fixed Issues
java:S3415 - Swap these 2 arguments so they are in the correct order: expected value, actual value. • MAJOR • View issueLocation: python-commons/src/test/java/org/sonar/plugins/python/NotebookParsingDataTest.java:103
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 changed
This hunk swaps the arguments of assertNotEquals so that the hard-coded expected value ("test") comes first and the actual value (empty) comes second. The static analysis rule flags cases where the expected and actual arguments are in the wrong order in assertion methods, which would produce misleading error messages on test failure. By changing assertNotEquals(empty, "test") to assertNotEquals("test", empty), the arguments now follow the correct convention of (expected, actual). This also addresses the related flow indicating that the other argument needed to be swapped, as both arguments are now in their proper positions.
SonarQube Remediation Agent uses AI. Check for mistakes.