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.