Why Scripting Languages are Better for Writing Automated End-to-End Tests? Part 1

If the test scripts are not plain-text in a scripting language, avoid it.

For programmers, the language a project uses/should use is quite a hotly debated topic. In this article, I’ll share my opinions on the kind of languages (scripting languages) that I recommend using for automated end-to-end tests. This article will remain objective but to give some background first, I:

• Work with Java at work

• Authored one Educative course in Ruby

• Am currently authoring a book on C# automation

Please note, all discussion points are with automated end-to-end testing in mind.

1. No Compile Step ✅

You can write tests in traditional compiled languages like Java or C#. Before running these tests, you need to compile them first.

In scripting languages, such as Ruby or Python, this compile step is not necessary. Instead, the code is interpreted at runtime.

The meaning of scripting (in scripting languages or other contexts, such as movies) implies execute instructions step-by-step. For this reason, scripting languages typically don’t require compilation.

2. Relative Path ✅

Most programmers know that using the absolute path can cause problems when executed on a different machine/operating system. Also, because the file (such as test data) not colocated with the test script, it is a recipes for troubles.

So, being able to specify that files/folders’ path relative to the script is necessary. Typciallly, test scripts refer to other files for test data or helper functions.

In Ruby, relative paths can be done easily. The test script below, uploads an image.

    new_professional_page.upload_image( testdata("woody.png") )

The test image file, in this case, woody.png, is located in the test script’s sibling folder.

def testdata(file)
    current_dir = File.expand_path File.dirname(__FILE__)
    File.expand_path File.join(current_dir, "testdata", file)
end

Compared to Java, where you will need to provide the classpath. It works (more complex) and makes sense to experienced Java users, but to newcomers it’s not very intuitive.

3. Ease with test execution: test files ✅ vs by test class

After the code is compiled, the meaning of the file (where the code is) no longer matters. From the app’s perspective, it only cares about the classes.

For example, in C#, the command 
dotnet vstest ./bin/Debug/net7.0/SeleniumRecipesCSharp.dll /ListTests

Lists all test cases in a compiled test package (a DLL).

Microsoft (R) Test Execution Command Line Tool Version 17.5.0 (x64)
Copyright (c) Microsoft Corporation.  All rights reserved.

The following Tests are available:
    TestLoginOKOnly
    TestLoginOK
    TestLoginFailed

Below are typical ways to run tests using VSTest.Console.exe (or dotnet vstest), the command-line tool to run C# tests.

1. Run all tests in a DLL, where the tests are packaged in.

dotnet vstest ./bin/Debug/net7.0/Foo.dll

2. Run an individual test class

dotnet vstest ./bin/Debug/net7.0/Foo.dll /Tests:NameSpace:Test1

3. Run an individual test case

dotnet vstest ./bin/Debug/net7.0/Foo.dll /Tests:NameSpace:Test1:Case2

Let’s see how the above is done for tests that are written in Ruby, a scripting language.

1. Run all tests in a folder
   rspec spec

2. Run one test script
   rspec spec/login_spec.rb

3. Run an individual test case
   rspec spec/login_spec.rb:18 
   Where 18 is the line number where the specific test case is “around”. This helps debugging because the failure message includes the line number so you can copy and rerun that specific test straight away.