Using Containers and Google cloud in Automation Testing
Using Containers for Automation Testing
With the advent of agile and continuous integration and deployment, continuous testing has become a requirement. There is no alternative to that. The emphasis on shorter release cycles to give the product an edge in the competitive market is crucial.
In the faster release cycles, maintaining the quality of delivery is a real challenge.
Case in point:
Let’s assume you build an accounts screen for a highly secured banking app. Now some of the users might be using Chrome to access the application, some might use Internet Explorer, some might use mobile apps, etc. Now in the mobile app also, some users may have an Android phone and some may have iOS. So while deploying the code on production, developers and testers have to make sure that the feature is compatible with all different OS, browsers, platforms.
In the traditional approach, the developer has to handle the environment-specific compatibility before each deployment. Containers save us from such dependencies. Containers provide a logical packaging in which applications can be abstracted from the environment. It doesn’t matter where it is going to run in a private data center, a public cloud, or a personal laptop. A container is a collection of code, environment configurations, dependencies all bundled together with an execution engine on a virtual machine.
A containerized test environment is often configured as close to production as possible. It gives a safe way to test a scenario in real-world like conditions before it actually goes to the real world. With the containers, you can get a well-maintained test environment without the implications of the development process. Test engineers can spin up the services and dependencies on their own test machines which would be available on production and run their automation suit.
So containers are here to make our lives easy.
An example of a container-based setup with Docker
Docker provides an API to operate containers in the state of resource isolation called Namespace. It does not launch the OS and thus makes it quite lightweight. For common test scenarios, 10 or more instances can run on a single server simultaneously. Clearly it is more efficient and gives enormous coverage for automation testing.
- Containers provide consistency of the environment. The tests are highly repeatable without the worry about environmental factors and dependencies.
- Another advantage of containers is that the dependencies and configurations are established once and can be used throughout the SDLC for continuous testing.
- Supports versioning. Rollback to the previous version is easy.
- Well managed test suits that are handy to set up and execute.
Let’s take an example of Selenium Grid. A Selenium Grid is used to configure the distributed execution of automation tests. It consists of a hub and many nodes. Each node can have a different execution environment and can be considered as a virtual machine. To setup a grid, we need to download the selenium server jar file and run it on each and every machine where we want to set up the grid. Docker solves this time-consuming task. To setup docker based Selenium Grid, we should follow these steps-
- Download Docker toolbox for Windows/ Linux machine and install it.
- Install Docker image for Selenium Hub and for each of the nodes which we want to configure. The Docker images are available on Docker’s official website- https://hub.docker.com/
- Start selenium hub from docker container.
- Start selenium nodes. Note that for cross-browser testing different nodes will have different browsers.
- Start test case execution.
The advantage of this approach is that once set up, it proves to be very efficient in case test cases need to be run on different operating systems and on multiple browsers. In those cases we can set up Selenium Grid with Docker.
Orchestration: One step ahead of containerization
Automating the containers, how about this idea? So here comes Kubernetes which automates containers. This process is called Orchestration.
Let’s understand first, what Kubernetes is and how it works.
Kubernetes
Kubernetes oversees the containers and balances the load among all the containers. In essence, Kubernetes automates the containers, managing the load among them by strategically distributing it. While running, if a container is down due to heavy load, Kubernetes manages by distributing the load to other containers.
Each instance in Kubernetes is known as Kuberlet. As we all know that without containers, we would need physical devices. Containers eliminate physical devices by eliminating device drivers and making it a candidate for cloud-based deployment. In this way, the entire application can be tested in cloud-based virtualized containers eliminating the physical devices which would be needed otherwise. This reduces the cost and also makes the process seamless.
Let’s have a look at Kubernetes architecture for a typical application-
The containers are called as ‘Pod’ in Kubernetes terms. So a single Kubernetes node can have multiple containers. As we know that development, testing, and deployment are integrated, it is essential to be ready to adopt that in testing as well. Lets us examine the advantages of using containers and Kubernetes clusters in automation testing-
- Fast- We can deploy selenium containers as and when required.
- Short-Lived- Selenium containers are destroyed once test ends.
Conclusion
Moving from traditional automation solutions to a fully automated and lightweight solution using containers and kubernetes can be really efficient if there are a large number of test cases. Also, it makes room for integrating it with the DevOps pipeline and moving testing to shift left.
So this can be proved to be a well thought off approach for enabling continuous testing in an agile environment.
Published on Java Code Geeks with permission by Arun Kulkarni, partner at our JCG program. See the original article here: Using Containers and Google cloud in Automation Testing Opinions expressed by Java Code Geeks contributors are their own. |