TeamCity
Powerful CI/CD for DevOps-centric teams
Configuration as Code, Part 6: Testing Configuration Scripts
In this blog post, we are going to look at how to test TeamCity configuration scripts.
- Getting started with Kotlin DSL
- Working with configuration scripts
- Creating build configurations dynamically
- Extending Kotlin DSL
- Using libraries
- Testing configuration scripts
Given that the script is implemented with Kotlin, 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 need to add the JUnit dependency to the pom.xml file
junit junit 4.12
We also need to define the test directory.
tests settings
In this example, we have redefined the source directory as well, so it corresponds with the following directory layout.
Once we have this in place, we can write unit tests as we would in any other Kotlin or Java project, accessing the different components of our project, build types, etc.
However, before we can start writing any code we need to make a few adjustments to the script. The reason is that our code for the configuration resides in settings.kts file. The objects that we declared in the kts file are not visible in the other files. Hence, to make these objects visible, we have to extract them into a file (or multiple files) with a kt file extension.
First, instead of declaring the project definition as a block of code in the settings.kts file, we can extract it into an object:
version = "2018.2"
project(SpringPetclinic)
object SpringPetclinic : Project ({
…
})
The SpringPetclinic object then refers to the build types, VCS roots, etc.
Next, to make this new object visible to the test code, we need to move this declaration into a file with a kt extension:
settings.kts now serves as an entry point for the configuration where the project { } function is called. Everything else can be declared in the other *.kt files and referred to from the main script.
After the adjustments, we can add some tests. For instance, we could validate if all the build types start with a clean checkout:
import org.junit.Assert.assertTrue
import org.junit.Test
class StringTests {
@Test
fun buildsHaveCleanCheckOut() {
val project = SpringPetclinic
project.buildTypes.forEach { bt ->
assertTrue("BuildType '${bt.id}' doesn't use clean checkout",
bt.vcs.cleanCheckout)
}
}
}
Configuration checks as part of the CI pipeline
Running the tests locally is just one part of the story. Wouldn’t it be nice to run validation before the build starts?
When we make changes to the Kotlin configuration and check it into the source control, TeamCity synchronizes the changes and it will report any errors it encounters. The ability to now add tests allows us to add another extra layer of checks to make sure that our build script doesn’t contain any scripting errors and that certain things are validated such as the correct VCS checkout, as we’ve seen above, and the appropriate number of build steps are being defined, etc.
We can define a build configuration in TeamCity that will execute the tests for our Kotlin scripts prior to the actual build. Since it is a Maven project, we can apply Maven build step – we just need to specify the correct path to pom.xml, i.e. .teamcity/pom.xml.
The successful run of the new build configuration is a prerequisite for the rest of the build chain. Meaning, if there are any JUnit test failures, then the rest of the chain will not be able to start.
Subscribe to TeamCity Blog updates
