March 7, 2017 // By Paul Grizzaffi
Most developers who have used multiple programming languages have a love/hate relationship with at least one of those languages, myself included. Sure, there are some zealots out there that insist “Language X” is the best language ever, but I’ve found that some languages are more appropriate in some contexts than others. That applies to languages for automation as well.
I’ve been a part of this conversation before:
“We should use C# for our automation language. Our developers already know it.”
“But do we expect testers that may not know how to code to learn C# and the automation tool?”
I’ve also been a part of this conversation:
“We should use Python for automation. A lot of testers already know some Python.”
“The developers user Java; learning a new language will slow down new feature development.”
There are valid concerns in each of these arguments. Using a language that a large part of the organization already knows, and with which some have a great deal of experience, can certainly accelerate an automation initiative. It’s also true, however, that strongly typed, object oriented languages (such as C# and Java) can have a rather steep learning curve, especially for those who have little or no programming experience. In this case, it might be the development team’s responsibility to help ramp up the test team, or it may be necessary to bring in external training. In the best case, the automation work would be shared across all roles in the team, each member contributing what he or she can. This kind of approach can work well with high-functioning Scrum teams; conversely, this kind of approach may be challenging for teams where there is a strong divide between the development teams and the test teams, either culturally or organizationally. Generally, these challenges must be addressed for the value of a common programming language to be realized. If the development team will be actively involved in creating automation along with the test team, using the language that the product is often a good approach.
If the desire is to engage the largest number of team members in the automation initiative as quickly as possible, then choosing a language with a shallow learning curve may be beneficial. In my experience, scripting languages like Ruby and Python are good candidates for this; they can be very forgiving when it comes to “syntactic sugar” such as parentheses and semicolons, especially Ruby. Additionally, their “duck-typing” concept can make working with objects a bit easier (though in some cases it can be a bit confusing so caveat emptor). The downside with this approach is that there may be no one on the team (or the organization, or the company) that has significant expertise in this language.
We might say “the developers should know how to learn new languages” and I agree with that statement. That said, there’s a big difference in being able to program in a language and having deep experience in that language. It’s true that most languages that would be candidates here are going to have similar and familiar concepts: classes, modules, loops, conditionals, etc. There can, however, be subtle, and not so subtle, differences that are only recognized with a lot of up front reading or by making many mistakes and refactoring. If the development team will not be actively involved in the creation of automation, using an “easier to learn” language may be our preferred approach.
I’ve also seen this situation: we can’t use our product development language with the tool that best meets our needs. Yikes! At this point we have to decide: is the lack of support for our preferred programming language a deal-breaker (meaning that that tool really wasn’t the most appropriate for us) or do we bite the bullet and choose the most appropriate language for automation that the tool also supports. This is a business and organizational decision that will be different for each of us.
As in product development, there is no “best language” for automation; we can do most things in most languages. We need to decide which language is most appropriate for our needs and in-line with our strategy, audience, and environment.
Paul Grizzaffi is a Principal Consultant at Magenic. This post was republished from his personal blog and can be found here.