The Perils of Choosing A Test Automation Language
La Guardiola, Senglea, Malta | Photography by Raphael Awoseyin
Much has been said about which programming language should be used for building your test automation scripts. This is easily one of the most contentious issues at the beginning of any test automation effort. There are generally two major schools of thought.
Same language solution: Choose the same language the application in question is written in.
Easiest language solution: Choose the language easiest for non-programmers (i.e. testers) to learn
I think the question to ask when faced with such a decision is ‘who is going to be writing the automation scripts?’. When asking from this perspective, the root of the parallels become more apparent. Most of the time, automation is done by either the testers or the developers, or sometimes both.
same language SOLUTION
Choosing the same language the application is developed in makes complete sense if it is to be written by the developers. They have already been writing unit tests, and perhaps some integration tests. Writing acceptance test scenarios is just the next step. And if it is to be written by the testers, well they’ll have a whole team of developers skilled in the language to back them up if needed.
But here’s the problem, what if the language of the application changes? A while back, I worked on a financial application built on a Microsoft shop complete with .NET. As the automation engineer, I just happened to have experience with C# programming so the choice of C# as the automation language was a no-brainer. But about a year later, it was decided that the C# heavy user interface was starting to show its age and we needed something more modern and snazzy. In came Angular; fluid, fast, and full of UX fireworks. We sought out developers with Angular experience, and trained current developers likewise. The testing done by the QAs were mainly front facing so we quickly found ourselves in a situation where the automation code no longer matched application code. Does this mean we need to rewrite all our code in TypeScript/JavaScript ? After all, the unit tests were re-written along with the front-end code development. Do we now start retraining our testers on a new programming language? If we expect developers to be ‘agile’ and ready to re-write applications in whatever the sexy new faster, better, stronger, language is on the market, is it a far stretch to expect the same from our testers?
Trust me, retraining testers on a new programming language takes some 360 motivation and top down insistence. Most testers do not share the same language hungry appetite we often see in developers. Mastering C# automation with Selenium when you don’t have a programming background is already not too shabby. Pushing the envelope would definitely meet some resistance.
But wait a minute… our tests are still capable of running. They have been built on a solid platform with the framework and test layers well separated. We would just have to change some of the page objects, but they’ll still run on the refactored application. So what’s the problem? If it ain’t broke, what we trying to fix?
It turns out we stayed with our C# scripts, at least initially, as the testers had already been trained on them and the implementation met our testing needs. However, some teams no longer had automation engineers and the developers were starting to take over the automation effort. And no surprise, they used and advocated for Protractor, a JavaScript or TypeScript based framework, as it made the most sense for them. Protractor is after all an end-to-end test framework built for Angular and AngularJS applications such as ours. When properly implemented, it can be faster and more reliable than other Selenium implementations in this context.
So do we switch to TypeScript/JavaScript as a testing language? Or do we stick with C#? And what if the application language changes again in the future? Should our automation suite be as nimble and open to change as our application?
Easiest Language Solution
How about we just go with the easiest language to learn and completely ignore what the developers are doing? The easiest language for non-programmers to learn for test automation tends to be a debate between Python and Ruby, with some JavaScript advocates. But the general consensus seems to be Python. ‘The Best Programming Language for Test Automation’, a blog post by Automation Panda does a great job explaining why Python is great for automation. So why don’t we push for such languages to be the golden standard for test automation?
Well, the truth is test automation IS programming. And even though there has been a recent rise in Python adaptors, staples such as Java and C# still prevail. If you have learnt object-oriented programming, it’s most likely your course was taught in one of the traditional object-oriented languages such as Java, C#, C, or C++. But this is slowly changing. More and more schools are starting to teach Python for beginner coders, and according to the TIOBE Index, as of January 2019, Python has become the 3rd most popular programming language after Java and C.
Conclusion
The holy grail would be of course to have the application built in a language that is easy for the testers to learn or that they already have experience with. But all things considered, the test automation language used says more about company culture than any other strategic thinking. We can talk about the ease of recruitment, the learning curve, and application code, but it often comes down to culture:
Same language as application; hints to developer-tester collaboration culture with a tendance to shift left on the testing spectrum
Easiest language; test automation independence, varying technologies, possibly testers without programming background.