The agile movement is making testers shift their tests to the left. From a practical perspective, this means that the testers are getting closer to the developers, and the testers’ automated tests need to be integrated with the developers tests (I discussed this in considerable length here, if you’re interested).
This is interesting. The shift-left movement now ties together the tester’s tests and the developer’s tests. This begs the question — should the tests be written in the same language?
I will try and convince you that answering yes to that question has many benefits to both sides.
Writing tests in a different language than the developer
When the tester writes their tests in a different language than the developers do, what naturally happens is that a barrier dividing the two tests exists. This barrier exists because:
- The developer will not want to add tests to the tester’s tests.
- The tester will find it difficult to help with the developer tests and to add to them.
- The developer and tester can’t share code and processes between them.
This is totally natural and would happen even between two developers on the same team that speak different language. But in an agile company, the testers and developers should be working together as close as possible in order to deliver the software. And this barrier impedes this.
If the company is not agile, the testers are in a separate team, and receive the “release” to ensure it’s quality, test it, and create a set of issues in the issue tracker for the developers to fix, build, and create a new release for the testers to test. In this configuration, it doesn’t really matter whether the teams are speaking the same language.
Writing tests in the same language as the developer
But in an agile company, this barrier, this wall, should not exist if the company wants to stay agile. And the first thing you need to do to enable communication between developers and testers, is to have them speak the same language.
(For the remainder of the post, I will focus on developing web applications, and ignore the other types of applications).
So what languages should the tester use? What languages do the developers use? This depends on whether the developer is coding in the backend or the frontend.
So now that we have the privilege of choosing the frontend developer’s language or the backend developer’s language, which shall we choose? And the answer, in my opinion, is to choose the language that is closer to the code you are testing.
First and foremost, the ability to work with the frontend developers:
- The tester tests can side by side with the developer tests. Green for the application, even for the developer, is only after both set of tests pass.
- If the developers changes something that fails the tests, the developers themselves can change the test to conform to these changes.
- The testers can aid the developers in writing unit and end to end tests.
- If the tester needs to test something, and the test is more easily written as a unit or integration test, the tester can easily do that.
- When a project becomes big, the test code also becomes big, and a lot of it is actually shared libraries that aid in testing. Now these shared libraries can be shared between the developer and the tester.
- Because it is mostly a frontend language, the amount of frontend testing tools is much bigger than in any language.
I’m convinced! How do I try it?
Yes! Let’s write a simple test. We’re going to write a test for the Todo list application that you can find here. And hopefully I’ll convince you that it’s actually pretty easy.
First, install NodeJS. We need version 8 or later. You can find download links here: https://nodejs.org/en/.
Next, we’ll create a directory for our project:
mkdir todo-tests && cd todo-tests
Now we’ll inititalize our project:
npm init -y
This creates a
package.json with information about our project’s dependencies.
Now let’s install the dependencies we need for our test:
npm install --save-dev jest selenium-webdriver chromedriver
(this might take a minute)
Now let’s write the test. Create a file named
That’s it. That’s all the code we need to test that the todo list runs, and shows the “todos” header.
Let’s run it:
And… the test passes:
Adding Visual Assertions
But we’ve just checked the “todo” title. We didn’t really check the whole page. We could go over each element in the page, to ensure that it is correct. Alternatively, we can use visual assertions (to understand what visual assertions are, read Applitool’s “Visual Testing as an Aid to Functional Testing” post). Let’s do that.
First, we’ll add theApplitool’s Selenium Eyes SDK to our project:
npm install --save-dev eyes.selenium
Let’s modify the code a bit. We will add initialization code for Eyes, and one line to visually assert that the page is the same. The final code is this:
To use the Eyes SDK, you need an API Key, which you can get by registering at the Applitools site, here. Once you have that, login and go to the Eyes admin tool, here. You will find the API using the following menu:
To make Eyes Storybook use the API key, set the environment key
APITOOLS_API_KEY to the key you have:
// Mac, Linux: $ export
// Window C:\> set APITOOLS_API_KEY=your-api-key
Now we can run the test again:
And… it passes!
With this test, we checked all elements in the page, and not just the todo.
An agile company should shift the testing process left, to be close to the code. To do that, testers need to be “close” to the developers and to the code they’re writing. To do that, it would be beneficial to both testers and developers that they both spoke the same language.