Testing in a QA Environment
DevOps is fundamentally about ensuring high quality code. At any point in time your code, which is being pushed from a developer machine into source control, is tested against a number of criteria including scalability, interoperability, performance, and others. Because microservices are commonly derived from a monolithic app that has been broken down into a set of independent services, it is important to make sure to test and validate that services interoperate with each other, and none are in a state that can break the larger system.
Integration Testing
When you have several microservices as part of a larger project, it is important to make sure that these services work given the interdependence with each other. There are several techniques that can be leveraged for integration testing. For example, Big Bang Integration Testing tests all the services running together at the same time to ensure that the entire system works as expected. Another option is bottom-up integration testing, where services at lower hierarchy levels are exposed to a set of tests, and subsequent services that depend on those services are then tested.
Coded UI Testing
Coded UI testing helps validate that end-to-end scenarios using multiple services work together. For an ecommerce site, this would include searching for a product, adding it to a shopping cart, and checking out to place an order. Coded UI tests help ensure that the integrated multiservice scenario doesn’t break.
Selenium (http://docs.seleniumhq.org) is an example of a cross-platform open-source web UI testing framework, that integrates directly with Docker (http://bit.ly/dockerselenium). Selenium tests can either be written in a programming language like Java, C#, or Ruby, or you can use the Selenium IDE which records everything you do in your browser, like the ecommerce browse-to-checkout example. One of the great benefits of Selenium is that it is both independent of the original language in which the web app was written and can run simultaneously in the context of multiple browsers on different systems. This results in a significant reduction of time investment for testing the same project in different situations.
Load & Stress Testing
Among the different types of performance tests, load testing ensures that application performance doesn’t degrade based on the size of the load placed on the service. Although a service can have great performance with a hundred customers an hour, you want to ensure the service will still perform under a heavier load when the number of customers increases to 10,000. Stress testing takes this further and tests what happens when you overload a service and it breaks.
Load Testing with Azure and Visual Studio
Microsoft Visual Studio 2015 Enterprise enables developers to record and automate load tests that execute in Azure, and it comes with 20,000 minutes of free usage to get started! These tests can be used for any web site or technology (Go, Java, Node, .NET, and others) and can be customized in a number of ways:
• Set variable time intervals between tests and steps in a test.
• Run multiple tests in parallel to simulate real-world usage patterns.
• Test network latency or mobile performance using network performance values that simulate a 3G or dial-up 56K connection.
• Test multiple browsers, including Internet Explorer, Chrome, and Firefox.
• Geo-distribute your load tests by having them run in different Azure regions like Western U.S., Northern Europe, or East Asia as shown in Figure 6.9.
By running the test you can start seeing real-time results as shown in Figure 6.10. You can find more information on how to configure and customize load tests at http://bit.ly/azureloadtest. Because these tests are scripted, they can also be integrated directly into your continuous delivery pipeline.
Docker Stress Testing
When working with Docker containers, it is often useful to be able to launch multiple containers on a single host—think of a distributed deployment scenario. Spotify, a popular music streaming service, deploys Docker containers across their server farms, both in testing and production environments. Given their scale, it is important to know when certain clusters might fail, so Spotify decided to create their own tool to handle stress testing—docker-stress available at https://github.com/spotify/docker-stress. Docker-stress enables Spotify to test the container density for a Docker host, meaning how many total containers it can have running at the same time. The tool can spawn a number of worker containers within a single host that can be alive for a limited period of time. Running it can be done through the following command:
./docker-stress -c 100 -t 15
This code will create 100 containers with a lifespan of fifteen seconds each. Docker-stress also enables you to monitor the status of the stress test using docker-monitor. The docker-monitor command shown performs a health check over a fixed time interval (500 seconds) and sends any failure results to the specified email address.
./docker-monitor –t 500 –e [email protected]