logo logo

Keeping Up With Your Test Automation Project Dependencies

Keeping Up with Your Test Automation Project Dependencies

Your test automation project is not working alone, it always requires some sort of dependencies. These are nothing more than libraries that help you with certain tasks. For example, for UI web testing, you might use the Selenium library. The dependency you might use for mobile testing could be Appium. And of course, there are tons more dependencies you might use, or that your dependencies might use. Are you keeping up to date with the latest released versions of your dependencies?

When a library or dependency is released, it is either a major release or a minor one. A major release usually happens when a large piece of work has been finished, a large functionality was implemented, or a major re-haul of existing code is being done.

In some cases, the major release does not offer backward compatibility. That means that if your project was using a previously released major release of the library, your code might not work properly with the new release. In this case, you would need to make some changes to your own code, in order to use the new major version of the library. For example, Selenium ‘2’ and Selenium ‘3’ were two major releases. Of course, the exact version of the released version was not 2 or 3, but instead 2.0.0 and 3.0.0. And, as we know, the upcoming release of Selenium will also be a major one, namely ‘4’.

Major releases do not happen frequently. But that doesn’t mean libraries aren’t released often. Minor releases are coming after a major one, and they mostly implement bug fixes or smaller features. Upgrading your dependency to a minor release version is usually hassle-free and without any issues for your own code.

It’s important to keep up with your dependencies’ releases and update the versions you are using in your test automation project to the latest ones. Here are a few tips for achieving this:

  • Perform updates frequently. You could allocate some time for this task once every few sprints. This way you can have dedicated time for searching for the latest versions of your dependencies and making the updates.
  • Perform updates frequently. If you don’t and think of putting off the update as much as you can, maybe forever, you might end up not being able to use the library anymore. Older versions might become deprecated or worse, deleted.
  • Perform updates frequently. This way you will avoid updating from a major version directly to the next major version, without the intermediate minor releases.
  • Perform incremental upgrades. If, for some reason, you did not manage to update to the intermediate releases, and you are forced to go from a major version to another major version, do this in steps. Identify a few minor releases that were done before the current major one. And update to the first one of them. Once you made sure everything is working properly in your own project, upgrade to the next selected minor version. Repeat the process until you get to the major version you want to upgrade to. This way, in case the dependency contains some breaking changes, you will more easily fix any code that needs it. It’s easier to identify issues when dealing with fewer changes rather than with a ton of changes.
  • Make sure your code is running properly with the new version of your dependency. Always compile your code after performing the update. And always run the most critical tests right after the upgrade, to make sure you did not break anything important.
  • Use only RELEASE versions. It’s ok to use an alpha or beta version of a dependency, for the sole purpose of checking what impact a future release of a dependency might have on your project. But don’t use such versions on a day-to-day basis. The same is valid for SNAPSHOT versions, as those are work in progress that constantly changes. Hence it could cause you some issues you did not expect when you are not expecting it.
  • Make the updates on a branch. You never know whether your project needs a lot of fixes to make it work properly after an upgrade or not. It is always best not to break the main branch.
  • Read the release notes of the dependencies when performing the upgrade. This way you are aware of what new features you can use from the library. But you can also find out what possible bugs were fixed that you were experiencing when using the library. Or what additional settings you might need to perform to use some functionality.

And, if you upgraded to a version and encountered a bug for it, don’t hesitate to raise a defect in the library’s defect tracking system, if it wasn’t already found 🐞

About the author

Corina Pip

Corina is a Test & Automation Lead, with focus on testing by means of Java, Selenium, TestNG, Spring, Maven, and other cool frameworks and tools. Previous endeavours from her 11+ years testing career include working on navigation devices, in the online gaming industry, in the aviation software and automotive industries.
Apart from work, Corina is a testing blogger (https://imalittletester.com/) and a GitHub contributor (https://github.com/iamalittletester).
She is the creator of a wait based library for Selenium testing (https://github.com/iamalittletester/thewaiter) and creator of “The Little Tester” comic series (https://imalittletester.com/category/comics/). She also tweets at @imalittletester.

Leave a Reply