org.sonar.l10n.py.rules.python.S5914.html Maven / Gradle / Ivy

Go to download

Show more of this group Show more artifacts with this name
Show all versions of python-checks Show documentation

There is a newer version: 4.23.0.17664

This rule raises an issue when an assertion result is constant.
Why is this an issue?
Assertions are meant to detect when code behaves as expected. An assertion which fails or succeeds all the time does not achieve this. Either it is
redundant and should be removed to improve readabity or it is a mistake and the assertion should be corrected.
This rule raises an issue when an assertion method is given parameters which will make it succeed or fail all the time. It covers three cases:

   an assert statement or a unittest’s assertTrue or assertFalse method is called with a value which will
  be always True or always False. 
   a unittest’s assertIsNotNone or assertIsNone method is called with a value which will always be None or never be
  None. 
   a unittest’s assertIsNot or assertIs method is called with a literal expression creating a new object every time (ex:
  [1, 2, 3]). 

Noncompliant code example
import unittest

class MyTestCase(unittest.TestCase):
    def expect_not_none(self):
        self.assertIsNotNone(round(1.5))  # Noncompliant: This assertion always succeeds because "round" returns a number, not None.

    def helper_compare(param):
        self.assertIs(param, [1, 2, 3])  # Noncompliant: This assertion always fails because [1, 2, 3] creates a new object.

Compliant solution
import unittest

class MyTestCase(unittest.TestCase):
    def expect_not_none(self):
        self.assertNotEqual(round(1.5), 0)

    def helper_compare(param):
        self.assertEqual(param, [1, 2, 3])

Resources
Documentation

   Python documentation - the unittest module 
   Python documentation - the assert
  statement