Testing Your Webservices Hosted in a Docker Container is 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 apps like a webservice) 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. Such process could potentially be cumbersome.
With TestArchitect, you can spring up the “testing stuff” to test your webservice within a Docker container as easily as flipping a switch.
How it works
Every time you spin up an image containing all necessary TestArchitect components (instructions to build such image are below), 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 webservice app is silently performed between the 2 containers so you won’t notice anything besides the normal 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.
Build the TestArchitect image
You can pull the TestArchitect image from LogiGear’s official account on Docker Hub to your local box with a simple command.
docker pull logigear/testarchitect:8.3
Note that the TestArchitect package is built upon scientific-linux: 7.3 and redhat-lsb-core. It contains all necessary automation components to run your test scenarios, such as: TA Controller, TA Playback, Automation libraries, etc.
You’re now ready to kick start the tests, but if you want to build your own container hosting TestArchitect (i.e. you want Windows instead of Redhat Linux), you can create a new Docker file using any text editor, and write the following commands.
- Add the TestArchitect installer to the image
- Run the installer silently
- Remove the installer
The script looks like this:
# Add TA installer to the image
ADD TestArchitect_X.X.X.XXX /root/
# Install TA silently and remove the TA build
RUN /root/TestArchitect_X.X.X.XXX –mode silent && rm -rf /root/TestArchitect_X.X.X.XXX
It’s highly recommended that you create a separate container apart from the container hosting your webservice so that the application under test can keep changing without affecting the stable “testing stuff.”
At the end of your Docker file, you’ll need to start TA Controller as below.
# Start TA Controller
TA Controller usually takes a few seconds to complete its startup, so you’ll have to wait a bit before executing the tests.
CMD sleep 5
The last step is to execute the TA batch file to kick off the test run.
Finally, you can now build your image using docker build, let’s name it: my-ta.
docker build –f myDockerFile.txt –t my–org/my–ta:X.X
Note that the X.X tag usually denotes the TestArchitect version living in the image.
Generate TA batch file
Assuming that you already have a full webservice test suite, you now need to select those test modules and generate a TA batch file from any TestArchitect Client connected to the desired repository.
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.
Run your container
You can run the prebuilt TestArchitect image or the customized my-ta image after building it.
This command spins up the my-ta image. Notice that it also mounts the /
docker run –rm -v ///d/test:/test my-ta
test folder in the container to D:\test folder in the host machine (-v flag). This mapping is necessary so that you can change which tests to run by copying a new TA batch file (mytests.sh) to this folder.
The –rm flag is there to automatically remove the container after finishing the tests.
Name the batch file as mytests.sh and copy it to D:\Test on the host machine.
- Make sure the container hosting your webservice is running beforehand.
- Remember to generate the new batch file and copy it to D:\Test before running your container if you want to change the tests.
- If you haven’t shared the hard drive on the host machine with Docker, it’ll throw an error. To do so, open Docker > Shared Drives and check on the respective drive.
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.