This post is part of the Pride & Paradev series.
What language should you use for your automated acceptance tests?
- Use the programmer’s language for your automated acceptance tests
- Let the testers choose a language for your automated acceptance tests
Use the programmer’s language for your automated acceptance tests
Automated acceptance tests shouldn’t be developed in isolation, so having these written in the same language as your application (usually C# or Java) will ensure that the programmers are fully engaged and will maximize the liklihood of having these tests maintained alongside your application code.
Even if the software testers are responsible for writing and maintaining the automated acceptance tests, having them in the same language the programmers use will mean that the programmers can provide support for any issues the testers have, and are more likely to collaborate with the testers on these. The testers also pick up knowledge of the language used for the core application which means they are more likely to be able to fix bugs that they find.
Strongly typed languages, like C# or Java, may at first seem daunting to software testers, because they’re more verbose than dynamic languages, but they are actually surprisingly easy to learn due to the excellent support provided by IDEs such as Visual Studio or IntelliJ.
Let the testers choose a language for your automated acceptance tests
If your software testers are responsible for writing and maintaining your automated acceptance tests then it makes sense to allow the testers to write these in whatever language they choose.
The benefit of a tester choosing a dynamic language like Ruby is that there are no licensing costs (unlike C# which requires Microsoft Visual Studio) and that means all testers have unconstrained access to these, as well as an unlimited number of build agents to run these tests as part of continuous integration.
As testers develop their skills in these languages they can quickly create throwaway scripts to perform repetitive setup tasks required for their story or exploratory testing: such as creating multiple records or rebuilding a database.