Integrating Ranorex Automation in TeamCity CI Processes

Oct 9, 2012 | Integration

Integrate In TeamCity
This blog post will discuss how to automate testing in the TeamCity CI environment using Ranorex automation and how to provide feedback for every committed change in your subversion repository.

As already explained in the blog post ‘Integrating Ranorex Automation in Jenkins CI Process’, continuous integration is a software engineering practice in which isolated changes are immediately tested and reported on when they are added to a larger code base.

The goal of CI is to provide rapid feedback so that if a defect is introduced into the code base, it can be identified and corrected as quickly as possible.

Value of Continuous Integration

The value of CI can be summed up with the following bullet points:

  • Reduce risks
  • Reduce repetitive manual processes
  • Generate deployable software at any time and at any place
  • Enable better project visibility
  • Establish greater confidence in the software product from the development team


TeamCity Server

Download the TeamCity setup and follow the installation instructions.
A download link and further information about TeamCity can be found on the TeamCity homepage.

TeamCity Build Agent

The TeamCity architecture comprises of the server and a “farm” of build agents which run builds and make up the build grid. The server only distributes the tasks of building the software with new code changes on the company’s build grid and provides the web UI; the job of actually building and executing tests is performed by and on the build agents.

To run Ranorex automation on your build agents, you have to make sure not to start them as a windows service since a service does not have sufficient rights to start UI-applications. If you have installed the Build Agent as a service, open the ‘Services’ tool (which is part of the ‘Administrative Tools’ in the control panel), choose ‘TeamCity Build Agent’ service, stop the service, and set the ‘Startup type’ to disabled.

Disable BuildAgent Service

The TeamCity Build Agent can be started manually using following command (from the installation folder of the Build Agent):

.binagent start

Note: You also have to make sure that a valid Ranorex license as well as the Ranorex main components are installed on your Build Agent if you are going to build/execute Ranorex automation code.

Version Control System

TeamCity integrates with a number of the most frequently used Version Control Systems, from which it obtains the source files to create your builds. For this blog we are going to use subversion as version control tool.

In this sample we have two solutions placed in our repository: the application we are going to test and the testing application.


To start the application under test from your test project, simply add a new ‘Run Application’ action to your recorder action table which starts the application under test using a relative path to the SVN working copy root.

Add Run Application Action

Add a new Project

After setting up the TeamCity Server, Build Agent and Version Control System, it’s time to add a new TeamCity project.

For this purpose open the Administration area of the TeamCity Server and choose ‘Create Project’ in the ‘Projects’ section.

Add New Project

Choose a name for your project and save your modifications.

Add a new build configuration by choosing ‘create a build configuration’, choose a title for the build configuration and define a folder for build artifacts. This folder will hold the generated Ranorex Report for each build.

Create Build Config 1

Create Build Config 2

Version Control Settings

Now, set up the version control system settings.

Create Build Config 3

For this purpose you have to specify the VCS root by choosing ‘Create and attach new VCS root’. In the next form choose subversion as VCS type and enter your connection settings. Additionally you can change the ‘checking interval’, which tells the TeamCity Server how often to check for changes within the repository.

Build Steps

After configuring the VCS you can add the following three build steps.

Create Build Config 4

First of all we want to build our application under test. To do so choose ‘Visual Studio (sln)’ as ‘Runner Type’ of your build step.

Create Build Config 5

And enter all relevant information regarding your application under test.


Repeat the steps mentioned above for your Ranorex Automation solution.

Create Build Config 7

To execute your Ranorex Automation, add a new ‘Command Line Execution’ build step which calls the Ranorex executable generated by the last build step.

Create Build Config 8

As you can see, you can define ‘Command Parameters’.

In this sample the command parameter ‘/zr’, which triggers the test suite executable to generate a zipped report file and ‘/zrf:.ReportsReport.rxzlog’ which defines the name and the location of the generated zipped report file, as well as the command parameter ‘tc:/TestCase’ which specifies the test case to be executed are used.

Note: Make sure to store the generated report files at the same folder you have specified as artifact path (./Reports) in the general build configuration settings. Otherwise the report files will not be added to your individual builds.

You can find a list of all available command line arguments in the section ‘Running Tests without Ranorex Studio‘ in our user guide.

The test suite executable returns ‘0’ on success and ‘-1’ on a failure which allows the test agent to either mark this build step as successfully or failed.

Note: From Ranorex 7.0, you can create a JUnit compatible copy of the generated Ranorex report file. The XML based JUnit test report can now easily be integrated into your CI build process.

Build Triggers

In order to trigger a build for every change committed, we have to add a build trigger.

For this purpose navigate to the ‘Build Triggers’ page, click on ‘Add new trigger’ and add a new ‘VCS Trigger’. Configure the trigger according to your individual requirements.

Add Build Trigger

Configure Notifications

To get notified about the build and test success of the newly created build configuration, you can configure an email notification.
For that you have to configure the connection settings of your ‘Email Notifier’ in the ‘Administration’ area.


After doing so you have to add a rule for notifying a specific user or a user group. Navigate to the ‘Users’ section in the ‘Administration’ area and open the settings for the user or group you want to be notified.

Open User Settings

Open the ‘Notification Rules’ tab and add a new email notifier rule.

Add New Notification Rule

In the ‘Add New Rule’ you can define the project or the build configuration and the status you want to get notified about.

Configure New Notification Rule

Run Job

Now that the configuration of the project has been finished, it’s time to see if everything works as expected.
To do so you can either run the build manually or trigger the build by committing a change to your subversion repository.

To run you build configuration manually simply click on ‘Run’ next to your build configuration in the ‘Projects’ area.

Run Build Configuration Manually

The build will be triggered on one of your configured build agents.
After the build is finished, you will get notified about the build by mail.

There will be a zipped report file attached to every triggered build which can be accessed via the ‘Artifacts’ column.

Successfully Executed Build


With this step by step instruction you will be able to easily setup a TeamCity CI process executing automated test for each committed change and rapidly providing feedback to the committer about the consequences of the changes.

Related Posts:

Secure Your Code, Harden Your App, Automate Its Testing

Secure Your Code, Harden Your App, Automate Its Testing

With DevOps practices more popular than ever in software engineering, there has been a push to integrate security, optimization, and frequent testing into the development process. However, as the baseline for what's considered good software evolves, so does the need...

A Guide to Test Driven Development (TDD)

A Guide to Test Driven Development (TDD)

For developers who work on many agile projects, test-driven development (TDD) may be something you wish to incorporate into your software development life cycle (SDLC). It’s a way to implement software programming while integrating unit testing, programming, and...