Languages I Use For Automation

  • Article

Mike asked what languages I use when I write test automation. It turns out there's a lot of them.

Right now I'm doing all my work in C#. The whole Office test team has shifted over to .Net languages for writing automated tests for the next version of Office. Once you're in .Net land the languages are pretty interchangeable - but most everyone is using C#.

But that's a recent development. I've used lots of other languages here too. In my time at Microsoft I've written automated tests or test tools in:

  • C#
  • C++
  • C (I learned to program in C++, keeping track of all the things I couldn't do in C was tough)
  • VB .Net
  • VB6
  • VBA (Visual Basic for Applications)
  • Perl
  • Several proprietary test tool scripting languages

Why so many? Well, programming languages are really just tools. Each of them has positives and negatives, and you need to choose the right tools for the task you're working on. Sometimes you need to use code libraries that are in a certain language (that's why we're doing all .Net now, a lot of people are writing shared .Net libraries so we don't duplicate work), sometimes I'm working with stuff the last guy wrote and I need to do it in whatever language he used (that's why I had to use C) and sometime you just need to do stuff that a certain language is really good at (I used Perl to do sophisticated comparisons of very large text files.)

In the end this is just another example of why it's important for testers to have a solid background in computer science. Once you get that background, learning new languages isn't hard and you can use the language that best fits the problem instead of trying to fit the problem into your language constraints.

Note: I want to be clear that learning a new language to write large scale systems is much harder. There's a difference between learning how to write code in a new language and actually writing good code in a new language. In general you shouldn't just switch around at will. But test applications are typically small enough that the learning curve is manageable. Plus the performance and reliability requirements of test code are much less then production code. In testing it's easier to bounce around between languages then in product development.

Chris