Python Unit Testing: One Time Initialization
By creating unit tests within class methods, developers can save time while testing Python code — learn how to do all of that and more in this quick read.
Join the DZone community and get the full member experience.Join For Free
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.
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.
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 –
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
setUp and tearDown Limitation
The fact that we can keep code that is common to all test methods in
tearDown is the most logical design. The only part about this design is the fact that
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.
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
The unit test class can also be executed by pytest, as
$ pytest mongo_test.py or
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.
Opinions expressed by DZone contributors are their own.