I try to be disciplined in writing tests, but it\u2019s usually not long before something gets in the way. Integration-testing interdependent APIs, verifying unusual server configurations, and seeding complex data make testing large applications tough. While plenty of solutions exist, I have found myself leaning on Docker more and more in the past year.<\/p>\n
If you aren\u2019t familiar with Docker, Barry Jones has written a great primer for Codeship\u2019s blog<\/a>. At a high level, Docker makes it faster and easier to spin up services using a variety of configurations. This translates into a number of advantages when running your tests in Docker:<\/p>\n Manuel Weiss covers some other great reasons that Docker makes testing more efficient here<\/a>, but in the remainder of this article, I\u2019ll focus on specific examples of how you can use Docker to improve your test suite. These examples are available in more detail on GitHub<\/a>, so feel free to clone the repository if you want to follow along.<\/p>\n Last year, I spent some time working with Maurits van der Schee\u2019s \u201cphp-crud-api\u201d<\/a>, an open-source PHP project that creates a RESTful API<\/a> from an existing relational database. The project officially supports PHP 5.3 through 7.1 in combination with Postgres 9.1+, MySQL 5.5+, MS SQL Server 2012+, and SQLite 3, which means there are dozens of combinations of PHP and databases to potentially support.<\/p>\n If you\u2019ve ever maintained an open-source package, you know how tough it can be to prevent breaking changes in older versions of the language. Docker makes this easier as you no longer have to set up and run multiple virtual machines to verify your application works. For example, let\u2019s say you have a PHP function that will sort an array of objects:<\/p>\n This function uses some of the newest features from PHP 7, including scalar type hinting<\/a>, return type declarations<\/a>, and the \u201cspaceship\u201d operator<\/a>.<\/p>\n In order to find out if this code will work with an older version of PHP, simply run the test (see the test code here<\/a>) from within a Docker container:<\/p>\n If you\u2019re not familiar with the Docker CLI or Now you have a simple way to verify that your tests will pass (or fail) in any version of PHP for which there is a Docker Image<\/a>. Unlike setting up and running a virtual machine, running a Docker container takes just seconds once you\u2019ve downloaded the image.<\/p>\n Another common problem that developers run into is knowing how their code will run on a new server. Even if you know which version of the programming language is running, you may not have all of the same extensions available. For example, PHP does not necessarily include the MySQLi extension<\/a>, so if your app needs to connect to a MySQL database, this will be a big problem.<\/p>\n Let\u2019s say you wrote a function that connects to your database and returns the version of MySQL:<\/p>\n If you test this (see test here<\/a>) in the default PHP 7.2 Docker image, it will fail:<\/p>\n This tells you that the code requires an extension that PHP doesn\u2019t have by default, but you can include it if you build your own Docker Image<\/a>. To build a custom image, add a Then build a new image and run your test in the new image:<\/p>\n Now your tests will pass, and you can commit this Dockerfile to ensure that other developers know this extension is required. If all the developers on your team commit to local development in Docker, it greatly reduces the all-to-common \u201cworks on my machine\u201d excuse.<\/p>\n Another challenge I ran into when testing PHP Crud API<\/a> was that it had to support four different databases and many versions of each. It would be nearly impossible to test every combination in virtual machines, but Docker makes spinning up and connecting to different databases very easy.<\/p>\n For example, if you want to run your tests in MySQL 5.6 and 5.7, you can start two containers:<\/p>\n The following PHP code creates a JSON column on your table (see the whole file on GitHub<\/a>):<\/p>\n The test for this code<\/a> makes sure the table was successfully created. Now you can run your tests against the MySQL 5.6 and MySQL 5.7 containers:<\/p>\n This tells you that the application will run with a MySQL 5.7 database, but not 5.6, and that can save you a lot of time debugging. You can use this same strategy to verify that updating your web server or caching service won\u2019t break your core codebase.<\/p>\n While running multiple versions of your language and services may be helpful for open-source projects, you might not have to worry about those situations in your day-to-day work. That said, there are still plenty of cases where Docker can help your test suite. For example, what if you need to seed the same data in your database every time you run your tests?<\/p>\n At The Graide Network<\/a>, we run a suite of microservices that can seed themselves independently, but when we want to run end-to-end tests, it\u2019s a little trickier. We use a SQL file mounted into our database container via a Docker volume<\/a> to make sure that the database is set up the same every time we run our tests.<\/p>\n For example, if you check some dummy data into your version control, you can make sure all developers use the same data to start their MySQL container:<\/p>\n The command above mounts the Unit and integration tests might make up the bulk of your test suite, but end-to-end tests should also play an important role<\/a>. At The Graide Network, we run a few dozen microservices, which makes end-to-end testing especially challenging. Fortunately, Docker Compose<\/a> has made testing our whole application much easier.<\/p>\n While many options exist for running end-to-end tests, I like Nightwatch.js<\/a>, a Node-powered browser testing tool. In order to run your end-to-end tests with Docker Compose and Nightwatch, you\u2019ll need to create a This Compose file starts three Docker containers: an NGINX server, a headless Chrome instance, and a Nightwatch test runner. Assuming your folders and What if your test suite requires a more complicated set of apps? For example, a Node backend app with a single page Javascript and HTML frontend?<\/p>\n Docker Compose can handle this setup as well<\/a>. Containers in a Docker Compose file are automatically networked together, you can use this method to start a Node API and NGINX webserver for the frontend:<\/p>\n When you run this set of containers using the same Docker Compose command we used before, they will automatically be linked and your frontend will be able to make API calls to the backend Node app using a DNS record that Docker sets. In the example above, this means your frontend will call the backend like this<\/a>:<\/p>\n Docker Compose has some other great features for complex applications like advanced networking options<\/a> and extensible Compose files<\/a>, so be sure to read the docs for more<\/a>.<\/p>\n Finally, automation is one of the biggest advantages to running your test suite in Docker. One way to do this is with Codeship Pro<\/a>, which uses Docker to run your application and test suite. Once you build a Docker Compose file that works locally, you can copy and tweak that file to create a Codeship Services configuration file<\/a>. Add a Codeship Steps<\/a> file to your repository and your app is ready to go.<\/p>\n To test out your Codeship CI configuration locally (and prevent wasting builds debugging configuration issues), you can download and run their handy CLI tool Jet<\/a>.<\/p>\n Because the Codeship Services file can run many containers at once, this method of automating tests makes it possible to automatically run your app in different version of the language, using different databases, or with anciliarry services connected.<\/p>\n Docker has helped improve our test suite at The Graide Network as well as many open-source projects I\u2019ve worked on. If you have your own tips for using Docker to improve your test suite, let me hear about them on Twitter<\/a> as I\u2019m always looking to learn more.<\/p>\n\n
1: Working with Older Versions of the Language<\/h2>\n
< ?php\r\n\r\nfunction sortArrayOfObjects(string $field, array $objects): array\r\n{\r\n usort($objects, function ($a, $b) use ($field) {\r\n return $a->{$field} < => $b->{$field};\r\n });\r\n\r\n return $objects;\r\n}<\/pre>\n# Running in PHP 5.6 leads to a syntax error\r\n$ docker run --rm -v $(pwd):\/app -w \/app php:5.6 vendor\/bin\/phpunit index.php\r\n> Parse error: syntax error, unexpected ':', expecting '{' in \/app\/index.php on line 12\r\n\r\n# Running in PHP 7.0 works\r\n$ docker run --rm -v $(pwd):\/app -w \/app php:7.0 vendor\/bin\/phpunit index.php\r\n\r\n> PHPUnit 5.7.27 by Sebastian Bergmann and contributors.\r\n> ...\r\n> OK (1 test, 2 assertions)<\/pre>\nrun<\/code> command, check out the official documentation<\/a> or this short tutorial on running a PHP script in Docker<\/a>.<\/p><\/blockquote>\n2: Testing Required Extensions<\/h2>\n
function getMysqlVersion(): string\r\n{\r\n $link = mysqli_connect(DB_HOST, DB_USER, DB_PASS);\r\n\r\n if (mysqli_connect_errno()) {\r\n throw new Exception(\"Connection failed: %s\\n\" . mysqli_connect_error());\r\n }\r\n\r\n $version = mysqli_get_server_version($link);\r\n\r\n mysqli_close($link);\r\n\r\n return $version;\r\n}<\/pre>\n$ docker run --rm -v $(pwd):\/app -w \/app --link database php:7.2 vendor\/bin\/phpunit index.php\r\n> Error: Call to undefined function mysqli_connect()<\/pre>\n
Dockerfile<\/code><\/a> to the project that adds the MySQLi extension:<\/p>\nFROM php:7.2\r\nRUN docker-php-ext-install mysqli<\/pre>\n
# Build a custom Docker image from our Dockerfile\r\n$ docker build . -t php-72-mysqli\r\n\r\n# Run our test using the new image\r\n$ docker run --rm -v $(pwd):\/app -w \/app --link database php-72-mysqli vendor\/bin\/phpunit index.php<\/pre>\n
3: Integration Testing Different Services<\/h2>\n
# Starts a MySQL 5.6 container\r\ndocker run --name mysql-56 --rm -d -e MYSQL_ALLOW_EMPTY_PASSWORD=true -e MYSQL_DATABASE=test mysql:5.6\r\n\r\n# Starts a MySQL 5.7 container\r\ndocker run --name mysql-57 --rm -d -e MYSQL_ALLOW_EMPTY_PASSWORD=true -e MYSQL_DATABASE=test mysql:5.7<\/pre>\n
\/**\r\n * Creates a table with JSON fields, a feature only available in MySQL 5.7+.\r\n *\/\r\nfunction createTableWithJsonFields(): bool\r\n{\r\n $link = getLink();\r\n mysqli_select_db($link, DB_DATABASE);\r\n $createTableQuery = 'CREATE TABLE IF NOT EXISTS '.DB_TABLE.' (id INT, json_field JSON);';\r\n if (!$result = mysqli_query($link, $createTableQuery)) {\r\n throw new Exception(\"Table could not be created.\");\r\n }\r\n mysqli_close($link);\r\n return $result;\r\n}<\/pre>\n# Connect to the MySQL 5.6 container and run tests\r\ndocker run --rm -v $(pwd):\/app -w \/app --link mysql-56 php-72-mysqli vendor\/bin\/phpunit index.php\r\n> Exception: Table could not be created.\r\n\r\n# Connect to the MySQL 5.7 container and run tests\r\ndocker run --rm -v $(pwd):\/app -w \/app --link mysql-57 php-72-mysqli vendor\/bin\/phpunit index.php\r\n> OK (1 test, 3 assertions)<\/pre>\n
4: Seeding Data with Volumes<\/h2>\n
docker run --name database --rm -d -e MYSQL_ALLOW_EMPTY_PASSWORD=true -v $(pwd)\/data:\/var\/lib\/mysql mysql:5.7<\/pre>\n
.\/data<\/code> directory into \/var\/lib\/mysql<\/code>, the folder that hosts MySQL\u2019s data files, so each time you start up this database, the same data will be present in the container.<\/p>\n5: Docker Compose for End-to-End Tests<\/h2>\n
docker-compose.yml<\/code> file in the root directory of your project:<\/p>\nversion: '3.5'\r\nservices:\r\n nginx:\r\n image: nginx:alpine\r\n volumes:\r\n - .\/app:\/usr\/share\/nginx\/html\r\n chromedriver:\r\n image: blueimp\/chromedriver\r\n environment:\r\n - VNC_ENABLED=true\r\n - EXPOSE_X11=true\r\n ports:\r\n - 5900:5900\r\n nightwatch:\r\n image: blueimp\/nightwatch:0.9\r\n depends_on:\r\n - chromedriver\r\n - nginx\r\n environment:\r\n - WAIT_FOR_HOSTS=nginx:80 chromedriver:4444 chromedriver:6060\r\n volumes:\r\n - .\/:\/home\/node<\/pre>\n
nightwatch.json<\/code> file are set up properly (check the example to see how you should do it<\/a>), you can run your Nightwatch suite with one single Docker Compose command:<\/p>\n# Run the nightwatch tests\r\ndocker-compose run nightwatch<\/pre>\n
6: Spin Up Multiple Services<\/h2>\n
version: '3.5'\r\nservices:\r\n api:\r\n build: .\r\n volumes:\r\n - .\/api:\/app\r\n nginx:\r\n image: nginx:alpine\r\n volumes:\r\n - .\/app:\/usr\/share\/nginx\/html\r\n chromedriver:\r\n image: blueimp\/chromedriver\r\n environment:\r\n - VNC_ENABLED=true\r\n - EXPOSE_X11=true\r\n ports:\r\n - 5900:5900\r\n nightwatch:\r\n image: blueimp\/nightwatch:0.9\r\n depends_on:\r\n - chromedriver\r\n - nginx\r\n - api\r\n environment:\r\n - WAIT_FOR_HOSTS=nginx:80 chromedriver:4444 chromedriver:6060 api:3000\r\n volumes:\r\n - .\/:\/home\/node<\/pre>\n
fetch('http:\/\/api:3000\/')\r\n .then(resp => resp.json())\r\n .then(function(data) {\r\n \/\/ Do something with the data\r\n });<\/pre>\n7: Automate Your Continuous Integration<\/h2>\n