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.
The value of CI can be summed up with the following bullet points:
Download the TeamCity setup and follow the installation instructions.
A download link and further information about TeamCity can be found on the TeamCity homepage.
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.
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.
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.
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.
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.
Now, set up the version control system settings.
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.
After configuring the VCS you can add the following three build steps.
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.
And enter all relevant information regarding your application under test.
Repeat the steps mentioned above for your Ranorex Automation solution.
To execute your Ranorex Automation, add a new ‘Command Line Execution’ build step which calls the Ranorex executable generated by the last build step.
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.
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.
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 the ‘Notification Rules’ tab and add a new email notifier rule.
In the ‘Add New Rule’ you can define the project or the build configuration and the status you want to get notified about.
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.
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.
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.
Ranorex Studio is renowned for its robust no-code capabilities, which allow tests to be automated seamlessly across web, mobile, and desktop applications. Beyond its intuitive recording features, Ranorex Studio allows custom code module creation using C# or VB.NET,...
It’s difficult for any IT organization to execute DevOps effectively without test automation. However, it’s often easier said than done. Overcoming the challenges of automated software testing can end up slowing down product delivery and impacting quality, the exact...
There are more and more Android testing tools available for mobile app developers. These are our favorites for performance, accessibility, and security.
