Why Scripting Languages Are Better Than Compiled Languages in E2E Test Automation?
Scripting Language Features that are More Suitable for Testing
In previous articles, I’ve discussed why I prefer to use Ruby as my test automation scripting language of choice. However, in general, scripting languages have advantages over compiled languages for E2E test automation.
1. Error Stacktraces show line number
Below is a screenshot of the error trace on a test execution failure on a BuildWise CT server.
From just the error trace, we know why it failed — it couldn’t pass the test step that “tries to click an element whose name attribute is ‘login’”. Looking further down the stack trace, you can see the test file, but do you know which test step? Keep in mind, there might be several of them in one test script.
Compared to the error trace shown for the test script in the Ruby scripting language.
It is much clearer. Also, if your CT server supports ‘Copy error line to Clipboard”, you can navigate to a testing IDE (such as TestWise) to quickly navigate to a failed test step. This makes debugging test failures easier.
2. Relative Path for Test Data
In compiled languages such as Java, referring to relative files is not straightforward, including it in CLASSPATH. This might be fine for code. But for E2E testing, referring to test data (files) is rather common, the dynamic-ness of scripting language is clearly at an advantage here.
3. Compilation should not be required
Automated scripts (including test scripts) should be easy and accessible to anyone on the team, not just developers. This includes not just reading them, but running them adhoc via the command line (e.g. to set up test data). Asking everyone to have the required software, learn the commands for compilation, etc. can add extra steps. Most scripting languages come out of the box and are more friendly to the less technical.
Related reading:
