Skip to content

Container technology has been enabling companies to pack various software components into a single physical package that can be used for various purposes. In mobile app testing, containers are extremely useful and can easily enable clean, secure and scalable test automation with the right set of tools, programming languages, frameworks and literally any software components that test scripts, automation components or application need for test execution.

Last week we discussed the benefits of containers for mobile app testing. In this blog, we’ll take a look at quite typical ingredients for iOS containers and how to use those for iOS test automation.

Software is eating the world.” by Marc Andreessen was a famous quote about the state of the software world expanding over everything. Containers have been in an essential role in this and containers have got extremely popular for a variety of use cases.

In a nutshell, containers can enable its users to create clean, portable, and consistent environment for mobile app development, testing and deployment. We’ve also found it the winning concept here at Bitbar to ramp up a clean, reusable and distributable environment for iOS test automation.

Containers for iOS App Testing

One of the greatest thing with containers for app testing is the architecture and its nature how quickly it can be ramped up and used for specific use cases. Containers provide a standardized way to divide apps, tools and other stuff into distributable containers. Breaking software components up this way offers the ability to place them on different physical and virtual components/machines, using in the cloud or with an on-premise solution. The flexibility provides advantages around components and provides the ability to quickly and easily make consistent packages.

As discussed, containers can incorporate a lot of different things that work as utilities and software components to aid testing and test automation effort for your mobile apps. So what goes into containers and how does the typical container image look like with different components? Here is our example:

Example of Software Components in Container

The Core Tools include all the basic development tools and in case of iOS it can be anything from Xcode to Fuse, Fastlane and others. And naturally all components and tools can be placed in containers with multiple versions. When a specific tool version is used, this can be configured in containers as well. Applications build for efficient mobile test automation must include an .IPA file and test package.

Programming language support provided with containers is also easy. Just include the installation package as part of the container and script will take care of getting it ready for test scripts, apps and others. In case of iOS Objective-C, Swift and some others provide a great foundation for tests.

With Apple products, iTunes or connector for it can be incorporated in a container as well.

Other dependencies and middleware pieces can help to make test automation straightforward, easy and effortless. In this category, some utilities for internet usage, downloading or uploading other components, as well as making certain functional testing capabilities possible, can be included in the container.

One of the greatest thing with containers for iOS app testing is that those can be included with a variety of different test automation framework versions. For example with Appium, we may have several relevant versions for app testing. This may include versions that work with older versions of Xcode as well as with the latest version. Keeping container up to date with the state of the art iOS app testing components is actually a trivial task.

For example, containers for iOS app testing and test automation could look something like this:

SW included in typical container for iOS App Testing

How to Run Containers Efficiently with Mix of Tools and SW

This is always a relevant question when customizing app testing environment and adding/removing tools or software components from it. But because of the clean separation of container components and other software, tests executed inside the container enable users to customize the environment any way they like during the test session. Also, the launch of test automation scripts is easy with container scripts or even from command line.

This is done by using the script that is used to launch the container session. Any shell command or tool that is installed on the container can be called from script. For instance, you can build anything with Maven:

mvn clean test –DexecutionType=serverside

or simply, install new additional libraries or tools with Brew, using the following command:

brew install python

To operate efficiently with containers, script must be configured and basically that is the force to drive execution of the test environment, tools and components. Here is an example of script:

	if [ "$(uname)" == "Darwin" ]; then
	elif [ "$(expr substr $(uname -s) 1 5)" == "Linux" ]; then
		echo "Unknown OS system, exiting..."
		exit 1
	echo "Extracting"
	if [ "$(uname)" == "Darwin" ]; then
	   	echo "Running iOS Tests..."
		mvn clean test -Dtest=IosAppiumExampleTest -DexecutionType=serverside
	elif [ "$(expr substr $(uname -s) 1 5)" == "Linux" ]; then
	    echo "Running Android Tests..."
		mvn clean test -Dtest=AndroidAppiumExampleTest -DexecutionType=serverside
	echo "Finished Running Tests!"
	cp target/surefire-reports/junitreports/TEST-*.xml TEST-all.xml


Containers provide an excellent way to build a clean and consistent testing environment for your iOS apps. This blog has dealt with a few examples of what can be included in those containers that are eventually executable in a local environment or cloud.

Happy iOS Container Building, folks!

Ville-Veikko Helppi

Mobile Testing Product Expert