Jenkins integration - request for input
Dear testers it is well known that Jenkins is used widely to automate builds and some test activities, even though it is not explicitly designed to support test automation execution. People write t...
Forum Discussion
"My rant is related to the fact that I tried (and utterly failed) to integrate TC into TeamCity months ago"
Funnily enough, we have a TestComplete project run as part of the nightly build process in TeamCity.
But I suspect my approach is different to yours.
All my logging and reporting is done via script extensions which essentially form a data driven testing framework. This is all driven by user populated excel datasheets. A central script unit acts as the driver for all this. So the script extensions and driver unit form the shell of our automation projects that can easily be used on any new project.
So TeamCity builds the AUT. It then also installs it. Next step is to pull down the repo containing the TestComplete project and run that using TestExecute on a dedicated VM.
The project outputs an HTML file on completion with headline results and a couple of file links. From those file links you can drill down into greater levels of detail for the entire test run. TeamCity interprets both the return code from TestExecute and a couple of elements of the HTML file to indicate overall success or failure.
We find it works really well.
A couple of clever uses of global variable and dummy folders to indicate whether the project is being run in local (development) space or network (build) space as the behaviour varies slightly between the two and it's all portable and easy to use.
Funnily enough, we have a TestComplete project run as part of the nightly build process in TeamCity.
But I suspect my approach is different to yours.
All my logging and reporting is done via script extensions which essentially form a data driven testing framework. This is all driven by user populated excel datasheets. A central script unit acts as the driver for all this. So the script extensions and driver unit form the shell of our automation projects that can easily be used on any new project.
So TeamCity builds the AUT. It then also installs it. Next step is to pull down the repo containing the TestComplete project and run that using TestExecute on a dedicated VM.
The project outputs an HTML file on completion with headline results and a couple of file links. From those file links you can drill down into greater levels of detail for the entire test run. TeamCity interprets both the return code from TestExecute and a couple of elements of the HTML file to indicate overall success or failure.
We find it works really well.
A couple of clever uses of global variable and dummy folders to indicate whether the project is being run in local (development) space or network (build) space as the behaviour varies slightly between the two and it's all portable and easy to use.