Python Unit Testing: One Time Initialization

Introduction

Recently, after writing a microservice to manage Create-Read-Update-Delete (CRUD) operations for a MongoDB database, it logically was time to write unit test cases. As I had developed the microservice using Python and Flask, the unit test also had to be in Python. For unit testing, I used the unittest package.

Writing Unit Tests

By writing unit tests, not only was I ensuring that I could run the same tests over and over again but, assuming that the underlying functionality of the micro-service had not broken, I could expect the same results for each execution. Moreover, as the number of REST functions increased, the unit tests would help me ensure that none of the existing functionality was broken. Additionally, the unit tests would help me reduce the total amount of time I needed to spend on testing the same functionality over and over again.

Initial Approach

As is the typical development method, I started writing test cases by defining one method per test case. Before the actual test functionality, I had to ensure that I had a valid database connection. Thus, the first few lines of each method were common across the test cases — that of creating a connection to MongoDB.

class TestDatabase(unittest.TestCase):

    def testGetAllDocuments(self):

        self.connection = connect to database

        doc = TestDatabase.connection.find({})

        self.assertTrue(len(doc) > 0)

if __name__ == "__main__":

    unittest.main()

setUp and tearDown

As you may have noticed, the initial few lines of code in each method are common — that of making a connection to the database. As this code is repeated in each test method, we might make mistakes while copying and pasting the code.

To help solve the copy-and-paste situation, the unittest package provides two special methods – setUp and tearDown. These methods allow us to place code that is common to each test case method. The only difference is that the setUp method is executed before the test method is executed, while the tearDown method is executed after the execution of the test method. I placed the connection creation code in the setUp method and the connection closure method is in the tearDown method.

xxxxxxxxxx

class TestDatabase(unittest.TestCase):

    def setUp(self):

        self.connection = connect to database

    def tearDown(self):

        self.connection.close()

    def testGetAllDocuments(self):

        doc = self.connection.find({})

        self.assertTrue(len(doc) > 0)

if __name__ == "__main__":

    unittest.main()

setUp and tearDown Limitation

The fact that we can keep code that is common to all test methods in setUp and tearDown is the most logical design. The only part about this design is the fact that setUp and tearDown are called before each test method execution. In our case, I was connecting to a MonogoDB database. This means that a new connection is created before each test method and is closed after each test method. While it takes only a few milliseconds to create a connection, it adds to the total time needed for the execution of all the test cases, particularly if the number of test cases is large (as was the case).

Class Wide setUp and tearDown

As it happens, the designers of this package are one step ahead of us. The unit test package allows us to define a setUp method for the class — a class method, namely setUpClass. Similarly, we can define a tearDown method for the class — tearDownClass. These methods are executed only once — once when the class instance is created and once when the class instance is destroyed.

By putting the connection creation code in this method, we end up calling it only once — when the class object is created. This method is not invoked before each test case, saving us the time needed for connection establishment. I used the setUpClass method to create the connection and the tearDownClass method to close the connection. The only thing we need to keep in mind is that a connection object is an object with a class scope. To use the connection object in the test method, we have to refer to it using the class name and not using self.

xxxxxxxxxx

class TestDatabase(unittest.TestCase):

    @classmethod

    def setUpClass(cls):

        cls.connection = connect to database

    @classmethod

    def tearDownClass(cls):

        cls.connection.close()

    def testGetAllDocuments(self):

        doc = TestDatabase.connection.find({})

        self.assertTrue(len(doc) > 0)

if __name__ == "__main__":

    unittest.main()

Note

It is important to remember that the test class has been derived from unittest. Hence, we need to include main and invoke unittest.main() in it. To execute the test case, we use

$ python mongo_test.p or $ python -m unittest mongo_test.py

pytest

The unit test class can also be executed by pytest, as

$ pytest mongo_test.py or $ pytest

Conclusion

A unit test is one of the mandatory hygiene factors that we have to adopt for our projects. By writing unit tests, we are not only reducing the amount of time needed for testing but more importantly, we are creating a mechanism that brings in transparency in testing. People no longer have to overthink the "Y" present in the Excel against a test case. By using unit testing, the "Y" means a successful test condition check. As the unit testing code can be examined by all stakeholders, it also brings in transparency and helps us address questions regarding test methodology and coverage.