Dockerize your TestArchitect tests

Run your TestArchitect API and headless browser tests inside Docker containers as easy as flipping a switch

Docker is a virtualization platform enabling you to create containers – mini virtual machines— which have their own predefined environment, including file system, libraries and settings. Best of all, these light-weight images eat up only a few megabytes of your storage, instead of several gigabytes like a full-blown virtual machine.

Since we package not only the app but also its running ecosystem, the greatest benefit of dockerizing your app (usually SOA microservices) is zero-dependency deployment from development to testing to production environment. However, during the test phase, somehow you still need to install and configure your automation tool of choice to run natively in the Docker environment. Such process could potentially be cumbersome.

With TestArchitect, you can spring up the “testing stuff” to test your API or web apps within a Docker container as easily as flipping a switch.

How it works

For your convenience, the TestArchitect team has published an official Docker image here. This image contains all TestArchitect components necessary to run the following types of tests:

  • API testing
  • Headless Chrome testing

Headless Chrome is a web browser without graphical user interface. It’s typically faster than the real Chrome thanks to not starting up the browser GUI and bypassing all the time a real browser takes to load CSS, Javascript and render HTML. Note that this image is based on Ubuntu 16.04.

Every time you spin up this TestArchitect image (more instructions on how to spin it up in the following sections), TA Controller is started. Once Docker executes the test triggering command, TA Controller automatically launches TA Playback along with related Automation libraries, and connects to the corresponding TA Repository Server to get the relevant test artifacts.

The download process is just-in-time, which means TA Controller “talks” to TA Repository Server right at the moment it needs a certain file.

Each interaction between TA and your API or web app is silently performed inside the containers so you won’t notice anything besides the run status that TA Command Line prints out on your console.

Since we already specified that the run results will be uploaded to TA Repository Server, you’ll need to open TestArchitect Client connected to the corresponding repository to view the results on any machine.

Get the TestArchitect image

Assuming that you already got Docker CE for Ubuntu, you can execute the below commands (with root privilege) to pull the official TestArchitect image to your local box:

$ docker pull logigear/testarchitect:8.3.4.5070

To spin up (run) the image you’ve just pulled, use this command:

$ docker run -it –rm -p 53600:53600 –name TAInstance1 logigear/testarchitect:8.3.4.5070

Voila! Now you got a TestArchitect container up and run.

Generate TestArchitect batch files (*.sh)

Assuming that you already have a full API or headless Chrome test suite, you now need to select those test modules and generate a TA batch file (*.sh) from any TestArchitect Client connected to the desired repository. Let’s name the file as mySmokeTest.sh.

To make sure the results are stored on your repository, you’ll need to turn on the “Automatically add results to repository” option when generating your batch file.

One last step to make the .sh batch usable is to edit it a little bit:

  • Insert #!/bin/bashas the first line of the file
  • Change the localhost argument to <ContainerName>, e.g. TAInstance1
  • Copy the *.sh file (sh) to any folder on your local drive (host machine). In this example, I’ll copy it to: /usr/local/local_test_data/Full_permission/Batch/

Run the automated tests

Now you’ve pulled the TestArchitect image in your local Docker repository, spin it up and generated the batch file containing the necessary automated tests (API or headless Chrome) to run at the right location. It’s time to actually trigger the automated tests using the following command:

$ docker run -it –rm -p 53600:53600 –name -v /usr/local/local_test_data/Full_permission/Batch/:/Batch/ logigear/testarchitect:8.3.4.5070 “/Batch/mySmokeTest.sh”

Your automated tests should be running at this moment. Running status will be displayed on the console.

After a few minutes (usually faster than a normal test execution on a physical machine), your test results will be available in the Repository Server. You can use any TestArchitect Client to connect to that repository and view the returned results.

Some notes:

  • Make sure the API under test or the web app under test is running beforehand.
  • Remember to generate new batch files (*.sh) and copy them to /usr/local/local_test_data/Full_permission/Batch/ before running if you want to change the automated tests to run.

Conclusion

Docker is much easier to control than the heavy-and-mighty virtual machines. For instance, you can spin up a container in a snap by just running a prebuilt lightweight image. This is extremely beneficial during the test development phase because it gives you the necessary convenience: run tests with different configurations while being able to develop more tests in one local box. Besides, Docker also enables scalability in your test execution. Spinning up hundreds of Docker containers to run TestArchitect tests is certainly way cheaper than hundreds of VMs.

Happy testing!

Thuc Nguyen is Associate Product Manager of TestArchitect, LogiGear’s flagship product which helps simplify creating and maintaining automated tests without coding. Thuc has a great passion for Agile, product management, UX design, and especially complex test automation problems.

Get TestArchitect Team Free





Thuc Nguyen
Thuc Nguyen has been leading the product teams at LogiGear in delivering quality Test Automation solutions to LogiGear’s customers and services clients. Thuc has a great passion for helping organizations transform their Test Automation, Continuous Delivery and DevOps practices, as well as empowering testers of all technical levels to thrive in complex enterprise environments.
Thuc Nguyen on Linkedin

The Related Post

It’s no secret that the cloud is growing at an exponential rate. By 2016, two-thirds of the world’s server workloads will exist in the cloud. But according to Cisco’s 2012 Cloud Index, less than half of server workloads currently run in the cloud. Closing the gap between current capabilities and future requirements is a mission-critical ...
From the culture shift, to differences in Agile, Dave Farley and Michael Hackett discuss the nitty gritty of Testing in DevOps. For this issue of LogiGear Magazine, our very own Michael Hackett sat down with one of the godfathers of Continuous Delivery, David Farley. In this exclusive interview, David discusses how test teams and automation ...
LogiGear Magazine June Issue 2020: Transform Your SDLC With Continuous Testing
Continuous Testing and Continuous Monitoring What is the goal of Continuous Integration? Is it to enable Continuous Delivery of the code developers’ produce out to users? Yes, eventually. But first and foremost it is to enable ongoing test and verification of the code. It is to validate that the code produced and integrated with that ...
Throw away clunky hyper-visors, and stop thinking about computer hardware and software license during your development projects. The first thing you think about when you hear “The Cloud” may not be development and testing. The Cloudy market is filled with SaaS applications, hosting, and cloud-based file systems. All are very useful, and offer a clear ...
Sauce Lab’s Perspective on Integration with Continuous Testing The term ‘DevOps’ implies that implementing an effective development and production workflow is as easy as developing the collaborative interaction between developers and IT operations. On the surface, DevOps may appear as a simple and straightforward idea but, as you will find out, there is more than meets ...
From adopting the culture, to implementing Continuous Delivery With the relative newness of DevOps, there are not yet a ton of DevOps books. That’s why we’ve assembled a list of the 7 best DevOps books based on four criteria: the number of ratings from Amazon, the average Amazon rating, number of ratings from GoodReads and the ...
DevOps for Test Teams By Michael Hackett Now that Dev Teams have had a little time to settle into the Agile, the new wave of process optimization has arrived. DevOps. DevOps has been described as Agile on Steroids. DevOps has also been described as Agile for Operations/IT. I like both of those descriptions as well ...
DevOps has been described as Agile on Steroids; DevOps has also been described as Agile for Operations/IT. I like both of those descriptions. Many organizations want Development, Test, and Operations teams to move to DevOps now. DevOps is a big topic, but DevOps is not the focus of this article. We will not be talking ...
Over the years we’ve provided an extensive number of articles, videos, and infographics that provide a wealth of knowledge about Continuous Delivery.
  LogiGear_Magazine_June 2016_Testing in the New World of DevOps  
Fitting QA into a modern DevOps group In a traditional software engineering organization, the QA group is often seen as separate from the Development group. Developers and testers have different roles, different responsibilities, different job descriptions, and different management. They are two distinct entities. However, for folks outside the engineering team – say in Operations ...

Leave a Reply

Your email address will not be published. Required fields are marked *

Stay in the loop with the lastest
software testing news

Subscribe