Kotlin Configuration Scripts: Testing Configuration Scripts
This is part five of the five-part series on working with Kotlin to create Configuration Scripts for TeamCity.
- An Introduction to Configuration Scripts
- Working with Configuration Scripts
- Creating Configuration Scripts dynamically
- Extending the TeamCity DSL
- Testing Configuration Scripts
In this last part of the series we’re going to cover one aspect that using Kotlin Configurations Scripts enables, which is testing.
Given that the script is a programming language, we can simply add a dependency to a testing framework of our choice, set a few parameters and start writing tests for different aspects of our builds.
In our case, we’re going to use JUnit. For this, we add the JUnit dependency to the pom.xml file
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
</dependency>
We also need to define the test directory
<sourceDirectory>Wasabi</sourceDirectory> <testSourceDirectory>tests</testSourceDirectory>
In our case, this corresponds to the following directory layout
Once we have this in place, we can write unit tests like in any other Kotlin or Java project, accessing the different components of our project, build types, etc. In our case we’re going to write a simple test that checks to see all build types start with a clean checkout
@Test
fun buildsHaveCleanCheckOut() {
val project = Project
project.buildTypes.forEach { bt ->
assertTrue(bt.vcs.cleanCheckout ?: false, "BuildType '${bt.extId}' doesn't use clean checkout")
}
}
That additional layer of certainty
When we make changes to the Kotlin Configuration Script and check it in to source control, TeamCity synchronises the changes and it will report of an errors it encounters, which usually are related to compilation. The ability to now add tests allow us to add another extra layer of checks to make sure that beyond our build script containing any scripting errors, certain things are validated such as the correct VCS checkout as we’ve seen above, whether the appropriate number of build steps are being defined, etc. The possibilities are essentially endless given that once again, we’re just using a regular programming language.
Update: Important note
Given that currently TeamCity does not fetch third-party dependencies, the tests, which usually require JUnit or some other testing framework, will fail if places inside the .teamcity folder. This is due to TeamCity syncing the project and failing to compile unresolved references. For now the workaround is to place the tests outside of this folder.
Subscribe to TeamCity Blog updates
