Scripting Languages vs. Non-Scripting Languages in Test Automation

I’ve used both scripting languages (Perl, Python, JavaScript, VBScript) and non-scripting languages (C, C++, C#, VB.NET, Java) to write test automation. Lately I’ve been writing the majority of my application code with C# and I’ve been using C# for my test automation too. When writing test automation, the two standard arguments for using the same, non-scripting language as used to create your application to test your system are that 1.) Non-scripting languages and development environments are more powerful, and 2.) That using the same language reduces test automation logic errors such as those generated by differences in data types. So, if those arguments are true then testing a C# application using test automation written in C# makes good sense. The single standard argument for using a scripting language for test automation is that scripting languages are very lightweight and have low overhead — just launch notepad, type, and run, as opposed to the pain of using a heavyweight tool such as Visual Studio. So, if that argument is true then testing a C# application using Python makes sense too. However, I’ve been experimenting with Microsoft’s new IronPython (essentially a "Python.NET") and noticed a couple of things about these standard arguments. First, there is really very little advantage nowadays to the lightweight aspect of scripting languages. Firing up and using Visual Studio requires virtually no more effort than using notepad these days, as opposed to the old days of separate compilers, editors, linkers, and help files running on machines with limited resources. So, at first thought, if the single advantage of using scripting languages for test automation is gone, then I should argue to always use the non-scripting C# (or similar) language for test automation. However, I noticed that when using the IronPython scripting language, I was forced out of my mental comfort zone and really thought about my test automation. I believe this is the true advantage of using a scripting language for test automation instead of using the same, non-scripting language you use to create your application — you become more creative. The bottom line is that if you write test automation, I think you need both scripting language skills and non-scripting language skills in order to maximize your testing productivity and value to your company or team.
This entry was posted in Software Test Automation. Bookmark the permalink.