In the previous section, we walked you through the complete cycle of TDD, in which we installed additional Python packages to complete our development. However, in the real world, one might work on multiple projects that might have conflicting libraries and hence, there is a need for the isolation of runtime environments. Before the advent of Docker technology, the Python community used to leverage the Virtualenv tool to isolate the Python runtime environment. Docker takes this isolation a step further by packaging the OS, the Python toolchain, and the runtime environment. This type of isolation gives a lot of flexibility to the development community to use appropriate software versions and libraries as per the project needs.

Here is the step-by-step procedure to package the test and visitor count implementation of the previous section to a Docker container and perform the test inside the container:

1. Craft a Dockerfile to build an image with the python3 runtime, the redis and mockredispy packages, and both the test_hitcount.py test file and the visitors count implementation hitcount.py, and finally, launch the unit test:

      ############################################# 
      # Dockerfile to build the unittest container 
      ############################################# 

      # Base image is python 
      FROM python:latest 

      # Author: Dr. Peter 
      MAINTAINER Dr. Peter <[email protected]> 

      # Install redis driver for python and the redis mock 
      RUN pip install redis && pip install mockredispy 

      # Copy the test and source to the Docker image 
      ADD src/ /src/ 

      # Change the working directory to /src/ 
      WORKDIR /src/ 

      # Make unittest as the default execution 
      ENTRYPOINT python3 -m unittest 

This example is also available on GitHub at https://github.com/thedocker/testing/tree/master/src.

2. Now create a directory called src, where we crafted our Dockerfile. Move the test_hitcount.py and hitcount.py files to the newly created src directory.
3. Build the hit_unittest Docker image using the docker build subcommand:

      $ sudo docker build -t hit_unittest .
      Sending build context to Docker daemon 11.78 kB
      Sending build context to Docker daemon
      Step 0 : FROM python:latest
      ---> 32b9d937b993
      Step 1 : MAINTAINER Dr. Peter <[email protected]>
      ---> Using cache
      ---> bf40ee5f5563
      Step 2 : RUN pip install redis && pip install mockredispy
      ---> Using cache
      ---> a55f3bdb62b3
      Step 3 : ADD src/ /src/
      ---> 526e13dbf4c3
      Removing intermediate container a6d89cbce053
      Step 4 : WORKDIR /src/
      ---> Running in 5c180e180a93
      ---> 53d3f4e68f6b
      Removing intermediate container 5c180e180a93
      Step 5 : ENTRYPOINT python3 -m unittest
      ---> Running in 74d81f4fe817
      ---> 063bfe92eae0
      Removing intermediate container 74d81f4fe817
      Successfully built 063bfe92eae0  

4. Now that we have successfully built the image, let's launch our container with the unit testing bundle using the docker run subcommand, as illustrated here:

      $ sudo docker run --rm -it hit_unittest .
      --------------------------------------------------------------- 
      -------
      Ran 1 test in 0.001s

      OK

Apparently, the unit test ran successfully with no errors because we already packaged the tested code.

In this approach, for every change, the Docker image is built and then the container is launched to complete the test.