Test Driven Development in Python: A Complete Guide to Unittest

Among the various programming principles, Test-Driven Development (TDD) is one that has gained traction significantly. This is because of the numerous benefits it offers in the development cycle, which includes better code quality, reduced debugging time and more.

For a beginner, you might ask, what is Test-Driven Development? Test-driven development is a development approach that involves writing tests before writing the actual code. This differs from the traditional programming style, where the code is written first before it is tested. Test Driven Development (TDD) follows a simple process whereby after writing the tests, you implement the minimum code needed to pass that test, which can then be refactored later on. Note the use of the term "minimum code" — this concept will be demonstrated in more detail shortly.

In this article, we will cover:

• The Test Driven Development cycle,

• Advantages of Test Driven Development,

• Test Driven Development in Python and the various tools used for it in the Python ecosystem,

• The basics of writing your first tests with unittest

• Solving real-world examples with Unittest using TDD principles

By the end of this article, you will have a comprehensive knowledge of Test-driven Development and be able to implement it in your Python development process.

Pre-requisites

• Must have Python installed

• An understanding of Python programming language

The Test-Driven Development Cycle

The TDD cycle is a development approach that emphasizes the need to write the tests before writing the code. It is an iterative process that consists of three main steps: writing the tests, implementing code to pass the tests, and refactoring the code. The cycle repeats itself continuously. Each of these steps is crucial to the TDD cycle as it ensures that tests are continuously tested and improved upon, leading to better code quality and more reliable software.

Step 1. Writing the test

The first step in the TDD cycle is to write the test for the functionality you want to implement. The test should mimic the expected behaviour of the code before the actual implementation. Of course! The tests would fail at this stage because the corresponding functionality does not yet exist. However, writing the tests first forces developers to clearly understand what the code is supposed to do. This step is also called the red phase because most times the tests fail, and the failures are usually depicted in red with most testing tools.

Step 2: Implementing code to pass the tests

The second step in the TDD cycle is implementing code to pass the tests. Here, the main goal is to write just enough code that is as simple as possible to meet the test requirements. Running the tests provides immediate feedback on whether the code meets the requirements, thus helping us catch errors easily. This step is repeated until the code passes the tests.

This step is also called the green phase, as depicted by the green checks, signalling that the code meets the defined requirements.

Step 3: Refactoring the code:

The third step of the TDD cycle is refactoring the code, Here, the code is restructured and organized to improve its performance without changing its output. This step comes last after iteratively writing codes to pass the test. This is because we can only refactor our code after it has passed the tests.

Refactoring is crucial for maintaining high-quality code over time. It helps to eliminate redundancies and enhance efficiency. Throughout the refactoring process, tests are continuously run to ensure that the functionality remains intact and no errors have been introduced.

This iterative process of testing, implementing and refactoring forms the core of the test-driven development cycle.

Advantages of Test-Driven Development

Test-driven development offers many advantages to the software development process. Some of the key benefits include the following:

1. Improved code quality: By writing tests before writing code, developers are forced to think critically about the functionality, requirements, and even edge cases, resulting in the use of cleaner architectures and designs.

2. Early bug detection and reduced debugging time: TDD enables developers to catch and fix bugs before they reach production; this significantly helps reduce debugging time in later development stages.

3. Integration with CI/CD pipelines: TDD is a crucial component of Continuous Integration and Continuous Deployment (CI/CD). By integrating TDD into CI/CD pipelines, developers can automate testing, improve code maintenance and provide better risk management.

4. It encourages simplicity because developers write only the code necessary to pass the tests; this helps prevent the addition of unnecessary features.

5. It saves costs in the long run: TDD can help reduce the time and resources spent on fixing bugs and addressing issues in later stages of development or production, thus saving costs.

6. Facilitates Refactoring: Refactoring is a major step in the TDD cycle. It involves optimizing code without introducing bugs or breaking existing features, thus improving code performance and maintainability.

Test-Driven Development in Python

The Python programming language is very robust and has a lot of various libraries that allow one to implement TDD effectively. Some of them include unittest, pytest, doctest, nose, and tox. However, while this article focuses on unittest, the same principles of TDD used here can be applied to others. Let’s take a closer look at how unittest it is used for TDD in Python.

Getting Started with unittest

unittest is Python’s built-in testing framework, modelled after Java’s JUnit (a test automation framework for the Java programming language). It offers a lot of features, which include:

• Assertions: unittest provides a wide range of assertion methods such as assertEqual, assertTrue, assertFalse, assertRaises etc, which are well suited for your testing needs. These assertions are used to compare expected and actual outcomes when writing tests.

• Automatic test discovery: unittest can automatically identify and run tests. This helps save time and also makes it easier to manage large test collections.

• Aggregation of tests: This feature of unittest allows you to group tests into collections and run them together. This helps in organizing tests logically, improving readability, and making it easier to manage tests based on functionality.

• Fixtures: unittest provides setUp and tearDown methods for managing test environments, enabling the setup and cleanup of configurations used for each test

• CI/CD Integration: unittest integrates seamlessly into Continuous Integration/Continuous Deployment (CI/CD) pipelines, thus automating the testing process and ensuring the reliability of your code.

Being part of Python's standard library, unittest requires no additional installation and is readily available in any Python environment.

Writing your first unittest

Having gone through a brief introduction about the unittest framework. This section will walk you through the basics of writing your first set of tests using Python’s unittest framework while focusing on principles learnt from the TDD cycle.

To write a basic test in unittest follow these steps:

1. Create a Python file and import the unittest test library into it:

    import unittest
   

   The name of the file does not need to start with the keyword “test" unlike in some other testing frameworks where this naming convention is mandatory. However, it is best practice to begin naming your test files with "test" (e.g test_example.py). This makes it easier for you and other developers to identify and manage.

2. Define a test class for your tests.

    class Test_Example(unittest.TestCase):
   

   Note: Your test class should inherit methods from unittest.Testcase or else the test methods defined inside the class won’t be invoked. This is because the unittest.TestCase class provides several assert methods that enable you to check for errors and bugs in your code. Some of the commonly used assert methods include:

   • assertEqual(a, b): This checks if a is equal to b.

   • assertNotEqual(a, b): This checks if a is not equal to b.

   • assertTrue(x): This checks if x is True.

   • assertFalse(x): This checks if x is False.

   • assertIs(a, b): This checks if a is same as b.

   • assertIsNot(a, b): This checks if a is not b.

   • assertIsNone(x): This checks if x is None.

   • assertIsNotNone(x): Checks if x is not None.

   • assertIn(a, b): This method checks whether a is in b, where b can be a list, dictionary, string, or any other iterable.

   • assertNotIn(a, b): This checks whether a is not in b.

While Python's unittest framework provides a lot of assert methods for use, be sure to check for the one suitable for your testing needs. For more information about other Python unittest assert methods, see Unittest assert methods

3. Define your test methods inside your test class

    class Test_Example(unittest.TestCase):
   
            def test_1(self):
                    pass
   

   Keep in mind that Python unittest framework follows a strict naming convention whereby all your test methods must begin with the test keyword. For example: test_string, test_numbers etc.

   Additionally, your test class can contain as many test functions as possible. However, some developers may create different classes to better organize their tests based on code structure and architecture.

   When you run the basic test written above, nothing happens. Why? This is because our tests have not been configured to run automatically.

   Note: Running unittest files follows the normal Python convention, where you use the python command followed by the file name. For example: python example.py

4. To fix this issue, add the following code at the end of our script.

    if __name__ == "__main__":
            unittest.main()
   

   In the code snippet above: The condition in the first line checks to see if the code is run directly and not imported as a module. If this condition is satisfied, the second block of code then invokes the unittest runner, which handles the automatic discovery and execution of the defined tests.

   Rerun the code, and this time, the terminal shows an output similar to the one below:

    .
    --------------------------------------------------------------------------
    Ran 1 test in 0.000s
   
    OK
   

   With this basic test setup and our test running as expected, the next section will guide you on how to read and interpret the results of your tests.

How to Read Unittest Results

Understanding how to read the results of your tests is crucial. It helps you assess if your code is behaving as expected. Remember, in TDD, you write the tests first, so interpreting the results accurately is essential to guide your subsequent code implementation.

Let’s use a simple test that checks if x is equal to 5 to understand it.

class TestEquality(unittest.TestCase):

    def test_value(self): #The test method must begin with test...
              x = 5
        self.assertEqual(x, 5)

In the code snippet above:

1. First, we defined a TestEquality class that inherits methods from unittest.Testcase

2. Inside this test class, we defined a test_value method that checks if the x is equal to 5 using the assertEqual method.

Run the code, and the terminal should show something similar to the following output:

.
----------------------------------------------------------------------
Ran 1 test in 0.000s

OK

The results show that our test passed successfully. Here’s a breakdown of what each part of the output means:

• ".": The dot represents each passed test. Here, we have only one test, and it passed, so we see a single dot.

• "Ran 1 test in 0.000s": This line indicates the number of tests run and the time taken to run them.

• "OK": This indicates that all tests passed successfully.

If the test had failed, you would see a different output. Change x to 3 and run the test again.

class TestEquality(unittest.TestCase):

    def test_1(self): #The test method must begin with test...
              x = 3
        self.assertEqual(x, 5)

When you run the test again, this time, the output differs from the previous one:

F
======================================================================
FAIL: test_1 (__main__.TestEquality)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\\\\Users\\\\hp\\\\Desktop\\\\TDD unittest\\\\test_example.py", line 8, in test_value
    self.assertEqual(x, 5)
AssertionError: 3 != 5

----------------------------------------------------------------------
Ran 1 test in 0.001s

FAILED (failures=1)

Here’s a breakdown of the output:

• "F": This indicates that a test has failed.

• "FAIL: test_1 (main.TestEquality)": This line identifies the test that failed, in this case test_1. This can be useful in identifying failed tests, especially when you have multiple test functions defined.

• "Traceback (most recent call last):" This provides a traceback of the error by helping you locate the exact line of code that caused the failure. In this case, the error came from line 8.

• "AssertionError: 3 != 5": This indicates that the assertion failed because the value of x was 3, not 5.

• "Ran 1 test in 0.000s": This indicates the total number of tests run and the time taken to run them.

• "FAILED (failures=1)": This last line summarizes the result by showing that one test failed.

Applying TDD to Solve a Real-World Problem with Unittest

Having understood the basics of writing and interpreting tests with python unittest, let’s solve a problem while applying the principles of TDD.

The problem we intend to solve involves creating a Python script that calculates the total cost of items in a shopping cart. Following the principles of TDD, the tests for this functionality should be written first.

Step 1: Write the test

import unittest
from main import calculate_total

class TestShoppingCart(unittest.TestCase):

    def test_calculate_total(self):
        cart = [
            {"name": "apple", "price": 0.5, "quantity": 4},
            {"name": "banana", "price": 0.25, "quantity": 6}
        ]
        result = calculate_total(cart)
        self.assertEqual(result, 3.5)

Here’s a detailed explanation of the code snippet above:

• The first two lines imports the unittest and the calculate_total function, which will be used to calculate the total cost of items in the shopping cart.

• Next is the TestShoppingCart class that inherits methods from unittest.Testcase

• Within this class is the test_calculate_total method, which contains a sample cart - A list of items where each item is stored as a dictionary with keys: name, price, and quantity and their respective values.

• The calculate_total(cart) function is called, and the result is stored in the result variable.

• Finally, the assertEqual method asserts that the calculated result is equal to 3.5

Run the test, and expectedly, our script fails with an import error:

Traceback (most recent call last):
  File "c:\\Users\\hp\\Desktop\\TDD unittest\\test_example.py", line 2, in <module>
    from main import calculate_total
ImportError: cannot import name 'calculate_total' from 'main'

This error is because the calculate_total functions haven't been implemented yet

Step 2: Implementing code to pass the tests

To fix this error, the minimum requirement to pass the test at this stage is to create a calculate_total function in the main.py file. The function does not need to contain any logic for now.

def calculate_total(cart):
    pass

Run the test again. This time, a different output is printed on the terminal.

The test fails with an Assertion error asserting that None is not equal to 3.5. This error is because None was returned, but 3.5 was expected.

The minimum code required to solve this error is to return 3.5.

def calculate_total(cart):
    return 3.5

Run this code, and our test passes.

Now that the first test has passed, let’s test our code implementation with a different cart.

class TestShoppingCart(unittest.TestCase):

    def test_calculate_total(self):
        cart = [
            {"name": "apple", "price": 0.5, "quantity": 4},
            {"name": "banana", "price": 0.25, "quantity": 6}
        ]
        result = calculate_total(cart)
        self.assertEqual(result, 3.5)

    def test_calculate_total_cart2(self):
        cart = [
        {"name": "orange", "price": 0.75, "quantity": 3},
        {"name": "grape", "price": 1.0, "quantity": 2}
        ]
        result = calculate_total(cart)
        self.assertEqual(result, 4.25)

Run the test again. This time, the test fails because the function still returns the hardcoded value - 3.0.

This time, we can modify the function to return 4.25 when a different cart is passed

def calculate_total(cart):
    if cart == [
        {"name": "orange", "price": 0.75, "quantity": 3},
        {"name": "grape", "price": 1.0, "quantity": 2}
    ]:
        return 4.25
    return 3.5

However, at this point, where things start to get repetitive, our solution would only work for these predefined cases but would surely fail should a different cart be tested again. At this point, we can implement a generalized function that can catch all test instances.

An easy way to solve this is through the use of python for loops that will enable us to iterate through all the items in the cart and then multiply the price of each item by its quantity and return the total value.

def calculate_total(cart):
    total = 0
    for item in cart:
        total += item["price"] * item["quantity"]
    return total

Run the test again. This time, our code passes the test.

..
----------------------------------------------------------------------
Ran 2 tests in 0.000s

OK

Note: This is how the TDD works. The minimum code required to solve the test is implemented at each step. While this approach may seem slow, it would be appreciated more in larger codebases as it helps in catching even the simplest bugs.

More Test Coverage

When testing, it is essential to provide enough test coverage to catch as many potential errors as possible. To achieve this, add tests that check for edge cases, such as an empty cart, a single item, items with zero quantity, and invalid inputs:

class TestShoppingCart(unittest.TestCase):

    def test_calculate_total(self):
        cart = [
            {"name": "apple", "price": 0.5, "quantity": 4},
            {"name": "banana", "price": 0.25, "quantity": 6}
        ]
        result = calculate_total(cart)
        self.assertEqual(result, 3.5)

    def test_empty_cart(self):
        cart = []
        result = calculate_total(cart)
        self.assertEqual(result, 0.0)

    def test_single_item(self):
        cart = [{"name": "apple", "price": 0.5, "quantity": 1}]
        result = calculate_total(cart)
        self.assertEqual(result, 0.5)

    def test_zero_quantity(self):
        cart = [{"name": "apple", "price": 0.5, "quantity": 0}]
        result = calculate_total(cart)
        self.assertEqual(result, 0.0)

if __name__ == '__main__':
    unittest.main()

Run the code, and our code passes all the tests.

....
----------------------------------------------------------------------
Ran 4 tests in 0.001s

OK

Should we stop here? Of course not! The previous steps have been all about writing and implementing code to pass the test. The last step of TDD is refactoring our code to remove redundant code and improve efficiency.

With this, I’ll introduce another feature of the unittest framework that enables us to refactor our code for efficiency.

Unittest Fixtures

Unittest provides a working environment for testing code called test fixtures. Fixtures offers the setUp and tearDown methods that allow us to initialize and clean up our code before and after each test method. By introducing test fixtures into our code, we can set the baseline conditions for running our tests and also avoid writing repetitive code.

The setUp method runs first before our tests are run, allowing us to set up any necessary preconditions for our tests. This feature is important in situations where you need to ensure that each test runs in a consistent environment.

The tearDown method is executed last after all the test methods have run and allows us to clean up any data used during the test.

Going back to our code, it can be refactored to include the setUp and tearDown methods. The setUp method initializes the cart variable before each test and prevents code repetition across our test methods. The tearDown method works differently; it cleans up the data by deleting all cart instances after each test. This helps prevent side effects/unwanted changes between tests, thus ensuring that each test starts with a fresh, unchanged state.

The code has been updated to include the setUp and tearDown methods, with print statements added at the beginning of the setUp and tearDown methods to show the order in which the code is run:

import unittest
from main import calculate_total

class TestShoppingCart(unittest.TestCase):

    def setUp(self):
        print("Setting up the test environment...")
        self.cart = [
            {"name": "apple", "price": 0.5, "quantity": 4},
            {"name": "banana", "price": 0.25, "quantity": 6}
        ]

    def tearDown(self):
        print("Cleaning up the test environment...")
        del self.cart

    def test_calculate_total(self):
        result = calculate_total(self.cart)
        self.assertEqual(result, 3.5)

    def test_empty_cart(self):
        cart = []
        result = calculate_total(cart)
        self.assertEqual(result, 0)

    def test_single_item(self):
        self.cart = [{"name": "apple", "price": 1.0, "quantity": 1}]
        result = calculate_total(self.cart)
        self.assertEqual(result, 1.0)

    def test_zero_quantity(self):
        self.cart = [{"name": "apple", "price": 1.0, "quantity": 0}]
        result = calculate_total(self.cart)
        self.assertEqual(result, 0)

if __name__ == '__main__':
    unittest.main()

Run the code, and the terminal shows an output similar to the following:

Setting up the test environment...
Cleaning up the test environment...
.Setting up the test environment...
Cleaning up the test environment...
.Setting up the test environment...
Cleaning up the test environment...
.Setting up the test environment...
Cleaning up the test environment...
.
----------------------------------------------------------------------
Ran 4 tests in 0.001s

OK

From the output, we see that the setUp and tearDown methods run before and after each test method, respectively, as shown by the print statements.

The setUp method initializes the test environment before each test, ensuring that each test runs in a consistent state. The tearDown method cleans up after each test, preventing side effects from any test to influence other tests.

Note: If the setUp() method raises an exception or error while setting up the test, the test methods would not be executed. Therefore, it is essential that the setUp methods are implemented properly without any errors to ensure all the tests run as intended.

For more information about test fixtures, see also: Test Fixtures.

For more information about core concepts of the unittest framework, see also: Unittest Documentation.

With unittest fixtures, we can refactor our test code, but how about the calculate_total function, should we leave it like that? No! It can also be refactored to make it more concise and efficient with Python built-in sum() function.

def calculate_total(cart):
    return sum(item["price"] * item["quantity"] for item in cart)

This new approach reduces the number of lines of code while still achieving the same functionality.

Conclusion

In this article, we've explored the principles of Test Driven Development in Python, focusing on unittest due to its easy setup and less complexity. We started with the basics of writing your first tests in unittest and gradually moved up to advanced unittest features - Fixtures. This article also demonstrated one core aspect of TDD, which involves implementing only the minimum code required to pass a test, thus preventing unnecessary complexity. While this article is focused on unittest, the various TDD principles outlined here can also be applied to other Python testing frameworks.
By following these principles and letting tests drive your development process, you’ll be able to write more reliable, maintainable, and efficient code.

References

Giordani, L. (2018). Clean Architectures in Python.