Containerization solves multiple problems in continuous testing (CT). Perhaps most useful is that it helps put end-users, testers and programmers on a more level plain so that they all see — and test — the same application. This eliminates the opportunity for coders to give their popular response “It works on my machine,” which is so notorious, T-shirts memorialize the excuse.
Simply put, containerization reduces the number of loose ends facing a development team.
Containerization benefits
Imagine a Java-based application. It works fine on a coder’s desktop. Standard Java practices give us confidence that a JAR file the coder prepares for the application makes its way safely to a tester’s desktop. However, the two installations might still behave differently for a variety of reasons: a skew in Java runtime engines, operating systems that differ too much, different sizes of disk partitions, and so on.
It’s too easy for the application to behave one way for the programmer and another for the tester, because the JAR, executable or program source determines such a small fraction of all that the program does.
A container, in contrast, ties up several of those loose ends. A container can fix the specific operating system the application sees, along with installed runtime libraries, resource allocations, timezone settings and more. Intelligent reliance on containers puts the programmer and the tester on a more level plane.
This argument may be even more applicable when the tester is a CT automation rather than a human at a keyboard. Once an application is properly containerized, a programmer can commit updates with much more confidence that a CT run will give the same results they saw on their desktop. Build managers can update or rebalance build machines, re-configure reporting, reroute networks, and more; as long as the CT container runner is active, it should yield the same test results as on the programmer’s desktop.
That’s not all. Containers also inherently make for cleaner tests.
State is one of the prime hazards of software testing — that one test might leave a test machine in a state to fool a subsequent test into a misleading result. Imagine a test that verifies proper handling of an attempted login by a non-existent account. It’s essential that no other test has created the non-existent account. One way to assure this is a consistent, fast setup procedure, which starts each test with a fresh copy of the environment that test needs. Containers provide exactly that fresh operating environment, minimizing the likelihood that state will inadvertently “leak” into a test.
Is your CT taking too long? One conventional approach to quicker completion is to send different tests to different machines, where they can run in parallel. Containers make this kind of horizontal scaling natural for your CT environment. Well-containerized tests migrate easily, not just between desktops, but also to whole new servers brought in to accelerate operations.
Containerization’s simplification of setup encourages explicit management of test data. Tight binding of tests and their specific data further enhances trust in CT results.
Containerization challenges
Newcomers to containerization, especially for CT, face several common challenges. Unpinned dependencies and unconfigured proxying are two specific puzzles that deserve attention.
Each dependence of a container definition can be configured as either the latest available version or a specific version. Whenever possible, choose the latter for each dependence. What is “the latest” can change between the time a developer commits their code and the time CT starts. Pinning dependencies eliminates that possible divergence.
Networking in a CT environment can be restrictive. CT is a target for certain malicious actors, and its networking deserves a corresponding weight of firewalls and other restrictions. Containers are abstractions within this restrictive environment, and container networking often requires special configuration before it can work as intended. Expect to work with your CT or networking specialist to get this set up when first launching a containerization project.
A good couple
Once you first get your CT and containers working together, you’ll find that both solve long-standing problems in your test operations, and you won’t want to return to life without them. While CT and containerization both present a few initial difficulties, they support each other and ultimately ease testing so you can concentrate on other opportunities.
Containerize, and make your CT work smoothly for you, and you’ll soon find you’re able to deliver better quality, faster.
