Where to save test automation scripts?

Jonatas Kirsch
Just Eat Takeaway-tech
4 min readFeb 18, 2020

I had a problem. While developers were pushing code to their repository, I was unable to test their implementations in the pipeline. I was unable to synchronise my tests with the branch a developer was working on. Therefore, if the developer pushed some code, then my tests did not cover this implementation before merging to the master branch. Also, the tests were outdated frequently; therefore, they used to report incorrect results.

This article describes how to solve these problems, i.e., how to:

  • Test implementations in the pipeline.
  • Synchronise tests with the branch that the developer is working on.
  • Make sure the tests are always up to date.
  • Report the right results.

During the last 13 years, I have experimented with several approaches in software testing, from working in a different sector to working together with developers. The diagram below illustrates the approach with a testing sector.

Developer codes application in a repository. Tester codes test automation in a different repository. Pipeline does not exist.
Process with a testing sector

With the advent of agile methodologies, testers started interacting more with developers. Now the role is more oriented to Quality Assurance (QA), and there is daily cooperation among team members.

Tests running in the pipeline

The more I worked in agile teams, the more I felt that the QA should provide mechanisms for testing a branch once a developer pushes code to the repository. By doing this, we receive instant feedback from our tests about whether or not the implementations our team did are working as expected.

We added tests in the deployment pipeline.

Developer creates a branch. Then the pipeline calls the master branch of a different repository where test automations are.
Tests running in the pipeline from a different repository

Then we faced some problems:

  1. When developer pushes code to the application repository then the test automation repository does not adhere to those changes. Therefore, tests fail in the pipeline (false feedback from tests for that branch).
  2. If we update the test automation repository at this moment, then our changes take effect in all pipelines even when some do not have the changes of one specific branch. Therefore, tests fail in all of the other pipelines (false feedback for other branches).
  3. If we have our continuous integration tool calling a branch with the same name in the test automation repository then we also face a problem because this branch does not exist in the test automation repository at the first time we push a branch. We face the first problem described above.

I could not trust the test results. Nobody could.

Testing at the same repository

Nowadays, it is possible to choose the technology we want for testing, among many, so we could code tests using the same programming language the developers use. As the QAs were working on the same team of developers, we were able to implement tests in the same repository they worked on.

When developer creates a branch then the pipeline runs with tests together, because code and test are in the same repository.
Tests running in the pipeline from the same repository

Now tests sync with the code. And we can adjust tests while we adjust the code.

This made it easy for developers to give insights and collaborate with QAs on improving tests, and vice versa. We are now able to automate a test even when the developer’s code has not been pushed yet — and we always get the right results from tests — awesome.

Improving the process

The last step was to improve the process with my team for being able to automate tests while we implement the feature, not after merging developer’s code.

Developer creates a branch. Then QA creates a branch for tests. Tests are later merged to the branch the developer created.
Developer and QA working together to achieve the goals

Problem solved! Now we test implementations in the pipeline. We synchronise tests with the branch that the developer is working on. Therefore, if the developer pushes code, then the tests cover those changes before merging to the master branch. Also, our tests are always up to date, and they report the right results.

Conclusion

We can code tests in the codebase when there are technologies supporting it. Independently of the codebase, it is worth checking whether or not the team can code the tests in the codebase.

When the tests are saved in the codebase then we can adjust the tests while we adjust the code, therefore the tests are up to date. The team can trust the test results. Also the practice of coding tests in the codebase increases the collaboration among team members.

Suggestions? Feedback? Feel free to comment here or find me on LinkedIn. Make sure to check out our careers page to discover tech jobs at Takeaway.com!

--

--