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

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 ...
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 ...
LogiGear Magazine – December 2013 – Cloud Testing
LogiGear University announces the launch of a new, free video series on Testing in DevOps and Continuous Testing which is available today.
Making the leap to CT is easier than you think— follow this guide to transform your testing process No pain, no gain! Achieving Continuous Testing shouldn’t take a “Hans and Franz” attitude. It should be painless, more like a natural progression from implementing certain practices over time.
This post is part of the Pride & Paradev series With continuous deployment, it is common to release new software into production multiple times a day. A regression test suite, no matter how well designed, may still take over 10 minutes to run, which can lead to bottlenecks in releasing changes to production. So, do ...
LogiGear Magazine June Testing in Continuous Delivery Issue 2017
Special considerations that should be applied to an application running in the cloud. Over the last weeks, I have found myself in several rather intense discussions about “cloud testing”: what it is, what it isn’t, and what it means for testing and QA professionals. The major source of confusion in these discussions usually revolves around ...
    Eric Minick is internationally recognized as a leading authority on continuous delivery and DevOps. Eric joined IBM four years ago with the acquisition of UrbanCode where he had worked as a developer, technical seller, and evangelist for a decade. Today, he has responsibility for leading the product management team overseeing continuous delivery solutions ...
  LogiGear_Magazine_June 2016_Testing in the New World of DevOps  
How to ensure a successful test-driven environment In order to ensure a higher quality product is released in the end, many teams have turned to test-driven development. Under this scenario, quality assurance metrics professionals first create various QA tests, and then software engineers code based on these tests, typically while using a robust enterprise test management ...
The book is an incredibly effective and valuable guide that details the risks that arise when deploying cloud solutions. More importantly, it provides details on how to test cloud services, to ensure that the proposed cloud service will work as described. It is a great start to the topic. The 6 chapters detail a paradigm ...

Leave a Reply

Your email address will not be published.

Stay in the loop with the lastest
software testing news

Subscribe