CI tools are revolutionizing the way we build and deploy our software, and incorporating automated test cases as part of the CI flow is an imperative step towards achieving product stability! There are a lot of great tools that implement CI/CD flows, such as: Jenkins, TeamCity, Travis CI, Bamboo and many more, but only 2 seem to lead the pack.
Jenkins is without a doubt the leading CI tool with a market share of almost 50%. In the second place, you can find TeamCity that takes up ~20% of the CI tools market share. The cool thing is that from now on, with TestProject‘s 100% free test automation platform, you can easily integrate your Selenium and Appium automated tests with both of these leading tools, by using a simple built-in plugin.
This article will guide you step by step through the process of setting TeamCity integration with TestProject. The TestProject plugin for TeamCity provides an easy way to execute TestProject jobs, update applications, data sources, project parameters, test packages and generate configuration for the TestProject Agent.
❗ Jenkins lovers – You can go ahead and read the full documentation here.
Prerequisites
- You need to have a TestProject account. Don’t worry, it’s 100% FREE.
- At least one registered and running TestProject Agent.
How to Use TeamCity Plugin
- Install the plugin in your TeamCity server.
- Go to ‘Administration’ > ‘Integrations’ > ‘TestProject’ > set your TestProject API key (which can be obtained here).
- Create a new build step and select ‘TestProject’ in the ‘Runner type’ dropdown.
- Now, simply select the action that you want to perform in TestProject.
Build Steps
Running a TestProject Job
Using this step, you can trigger TestProject jobs as part of your TeamCity test build. To trigger a job, you need to provide the following parameters:
Project Id– The ID of the project containing the job.Job Id– The ID of the job to execute.Agent Id(optional) – The ID of the TestProject agent that will execute the job. Leave this field empty to use the default agent defined for this job.Wait to finish– How many seconds should the step wait for the automation job to finish. If 0 is provided, the setup will not wait for the job to finish execution.Path to the JUnit XML report(optional) – Path (including the file name) to a file where the JUnit XML report will be stored. The file path can be absolute or relative to your workspace.Execution Parameters(optional) – A JSON object that allows you to override the job’s default settings and parameters for a single execution. Here’s an example:
{
"browsers": [
"Chrome"
],
"devices": [
"AAA111BBB"
],
"queue": true,
"restartDriver": true,
"projectParameters": {
"ProjectParameter1": "Value1",
"ProjectParameter2": "Value2",
"ProjectParameter3": "Value3"
},
"testParameters": [
{
"testId": "string",
"testPosition": 0,
"dataSourceId": "string",
"reinstallApp": true,
"data": [
{
"TestParameter1": "Value1",
"TestParameter2": "Value2",
"TestParameter3": "Value3"
}
]
}
]
}Please visit our API documentation to read more about using execution parameters when running a job.
Updating a Mobile Application (apk/ipa) File
Using this step, you can update an existing Android or iOS application file as part of your build. The step accepts the following parameters:
Project Id– The ID of the project containing the application.Application Id– The ID of the application to update.Path to the .apk/.ipa File– The path toapk/ipafile. The file path can be absolute or relative to your workspace.
Updating a Web Application URL
Using this step, you can update the URL of a web application. The step accepts the following parameters:
Project Id– The ID of the project containing the application.Application Id– The ID of the application to update.Application URL– The new URL address.
✅ You can explore additional build steps in our full documentation of the TeamCity integration.
Awesome blog and thanks for sharing information.
Thank you, @clearsky!