Fix Assert order regarding the report from sonarQube

[dawidkwiecien]

Description

I've found in SonarQube 90 issues regarding the Swap these 2 arguments so they are in the correct order: expected value, actual value.

Motivation and Context

I would like to fix it due to it was easy and fast thing

How Has This Been Tested?

I've runned ./gradlew test and tests still pass

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)

Checklist:

• [x ] My code follows the code style of this project.
• I have updated the documentation accordingly.

[milamberspace]

Thanks for the cleanup, and welcome! 👋

This is a clean, purely mechanical fix: it swaps assertEquals(actual, expected) to the JUnit order assertEquals(expected, actual) across 7 test files. I went through the diff (including the 77 swaps in ClutilTestCase.java) and every one puts the expected value/constant first — the change is symmetric (91−/91+), touches only assertEquals, and leaves the assertion semantics unchanged, so it only improves the failure messages. No 3-argument (message) calls were mis-ordered, and no other assertions were touched. Static analysis (Error Prone) passes.

On the red CI jobs: they are unrelated to this change. An assertEquals argument-order swap cannot turn a passing test into a failing one (assertEquals is pass/fail-symmetric), and the failures are confined to specific macOS/Windows locale cells (de_DE, fr_FR, tr_TR) — one was a confirmed gradle-cache-action HTTP 504 (a CI-cache infra timeout). The mainstream matrix jobs and Error Prone pass on the same code.

Approving — nice, low-risk improvement.

---

This review was drafted with an AI-assisted tool and confirmed by an Apache JMeter maintainer before posting. It may contain mistakes — reply if anything looks off.

[vlsi]

This is nice and mergeable. It would like if someone could explore the ways to add tests to avoid re-introducing this type of errors in the future.

[milamberspace]

Good point — worth tackling so this doesn't creep back in. A few concrete options:

1. Add SonarCloud PR analysis to the CI (best fit). This exact class of issue is SonarQube rule java:S3415, which is how these 90 were found. JMeter already has the org.sonarqube Gradle plugin wired (org apache, project JMeter), but today it runs out-of-band — a nightly report to https://sonarcloud.io/dashboard?id=JMeter, not a per-PR check. That's why these accumulated unnoticed. Wiring a sonar step into the PR workflow (SonarCloud supports PR decoration + a "Clean as You Code" gate that fails a PR introducing a new violation) would catch this at review time. S3415 is heuristic (name-based — it fires when a literal/constant sits in the "actual" slot), so it catches the common cases, not 100%.

2. Error Prone ArgumentSelectionDefectChecker. We already run Error Prone (the "Error Prone (JDK 21)" CI job), so this is the cheapest to trial. Its argument-selection check can flag swapped variables whose names don't match the expected/actual parameters — though it's unreliable for literals. Worth evaluating whether promoting it to an error is net-positive vs. noise.

3. AssertJ migration (largest, most durable). assertThat(actual).isEqualTo(expected) makes the order unambiguous by construction — there's no "which arg is expected?" left to get wrong. A big, separate effort, but it removes the whole class of bug instead of policing it.

My take: (1) is the most direct — it targets exactly this pattern and JMeter is already on SonarCloud; the missing piece is running it on PRs rather than only nightly. Happy to open a follow-up issue to track it.