Sonar Python assertEqual advice for unittest is incorrect

Rules and Languages Report False-positive / False-negative...
1

Hi.

For Python, rule S3415 is incorrect. The order of arguments to self.assertEqual in unittest is expected, actual. The rule states incorrectly that the order is actual, expected for unittest. This results in false positives for instances where the first argument to assertEqual is a literal. SonarQube Cloud is the instance that reported this.

import unittest
from local.repo import TestingService

class TestService(unittest.IsolatedAsyncioTestCase):
    def setUp(self):
        self.service = TestingService()

    def test_assign_response_with_empty_string_error(self): 
        primary_decision, primary_reason = self.service.assign_testing_response(
            "",
            ["accept", "primary-reason"],
            ["deny", "retry-reason"],
            "txn-1"
        )
        self.assertEqual("accept", primary_decision)

is one such test against which this rule was raised.

Regards.

James

2

Hey @JRBail, welcome to the Community! I’ve had a look at unittest’s docs and the method documentation itself doesn’t state it explicitly, but all their examples seem to follow the “actual, expected” pattern. For example: unittest — Unit testing framework — Python 3.14.6 documentation . Where did you see that the order should be the opposite?

3

I’ve come to realize that it is PyCharm doing its own thing - reporting expected as the first parameter and actual as second parameter in test results.

Some minor feedback: I do think that creating a rule based on examples in this case seems to lack solid footing particularly since unittest defines the arguments to assertEqual as (first, second) - not (actual, expected) - in their documentation.

4

I see your point, however, it might make sense to still recommend an order that is closely aligned as possible to the usual conventions in other libraries (principle of least surprise). I’m going to flag this for the team in charge of rule definitions in case they want to review it.

9

Hi @JRBail,

Thank you for reporting this.

As this rule was slightly too strict and trying to enforce a convention many didn’t like, its behavior was revisited in release 5.28.0.35681. Now, this rule only raises an issue if assertion orders are mixed within a file, allowing you to use whichever convention you prefer as long as you stay consistent.

Thanks again for your report and for helping us improve our products!