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

Do you want to speed up your automated tests by a factor of 10 and deploy your application continuously? In this article we share how the JIRA development team at Atlassian has accomplished this using Stages in Bamboo. Stages have allowed the JIRA Development team to take a week’s worth of testing and condense it ...
As a software development company, what is your goal? What is the one thing you feel you need to do to ensure you have a job at the beginning of each wonderful work week? The answer is actually quite simple; You need to deliver a quality product. Like how I used the word simple? Although the answer I ...
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 ...
LogiGear Magazine June Issue 2018: TESTING in DEVOPS
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 ...
Times have changed, the tools have improved, and with books like this available you have no reason to not give CI a go. I still remember the first time I was on a project that used NAnt and CruiseControl.NET. It was years ago and both were new tools with plenty of bugs. The project manager ...
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 ...
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 ...
Disclaimer: This article was originally published in the LogiGear Magazine, but has been updated for the June 2020 issue. Leading an organization into Continuous Delivery is a daunting task that usually takes software development teams months if not years. This guide covers the main points that organizations need to consider to increase their chance of ...
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 ...
Having the right skills and experience, even if you have to go outside, is essential for designing tests for large-scale cloud deployments. Moving existing applications to a cloud environment adds new dimensions to testing. One of the primary reasons for moving to the cloud is scalability. Capacity to handle traffic and data transfer can be ...
LogiGear Magazine June Issue 2020: Transform Your SDLC With Continuous Testing

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