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