As a result of the work on building Dockerfiles to build Docker images that can then be run with the same build, I considered testing the files as it as being developed. This provides confidence that the file and Docker are installing the desired packages and that these packages can be run. One of the the issues that I’ve been thinking about is how to test the container to test that a package is installed correctly. I also wanted to test the operating system image that is called.
Test Driven Development (TDD) seemed to be a solid approach to issues for Dockerfiles. I knew of the Puppet workflow with supporting libraries but the Docker practices are still relatively new to me.
The testinfra [1] Python library can be used to run tests in a more unit testing manner once the machines are installed (and it works across operating systems). This package should be explored further. It could contribute to the overall sustainability of the development and operations ecosystem. At the time, I was looking more at a Behaviour Driven Development (BDD) approach and wanted something that could be run whilst developing the code using feature stories as rolling documentation.
Using the guidance from the rspec-docker Ruby library, I wrote some lightweight prototype testing scripts in Python using Behave and Python. The Behave library is used to write the tests in a common language that is then translated into machine readable tests.
Behave is a Python version of Rspec that uses the Cucumber language to link the features written in the domain common language to the feature tests. This provides user acceptance tests. As a Behaviour Driven Development testing tool that uses the Gherkin language, Rspec allows the tests to be written in a way that is understandable.
Our prototype allows me to test a Dockerfile as it is being built and to run user tests to provide smoke tests for the system before deploying. Simultaneously it provides documentation on how the file works and its assumptions as this could be different from how the Dockerfile works, such as its part in a workflow.
At this stage, it is incomplete and would ideally require tests on the external interfaces to ensure that they are working as expected. My original curiosity about building the Dockerfiles with existing test practices and including them in the software development lifecycle is answered: it can be. I am in the process of taking this somewhere else at the International Digital Curation Conference in 2017.
[1] http://testinfra.readthedocs.org/en/latest/
No Comments