Most of the times your automation code project travels around, from machine to machine, to where the tests inside it need to run. Sometimes it might be your colleague’s machine, who also wants to run/update/add tests, but other times it will be some CI/CD entities, like physical or virtual machines, containers, and so on.

But in some cases, it is not enough for someone to just download the project onto their machine and start the test run. Some additional set up might be required.

For example, I remember quite a while ago, when, in order to run Selenium WebDriver tests, you would need those driver files downloaded to a location that the tests knew of. Without them, the browsers could not be open by Selenium. That was one situation where, on some projects, people got creative when it came to running tests on CI machines, by manually copying the driver files onto each of those machines.

That was difficult to manage due to 2 factors: you needed specific files for each operating system you were running on (for each browser you needed to support); and whenever a new version of those files came out, you needed to replace the existing files with the new versions, on each machine where they were initially copied. And of course for the first situation you needed some iffy code (code with ifs) to find those files in the correct location, based on the operating system you were using. Plus, it would also sometimes happen that the testers did not have access to copy any files to the CI nodes where tests ran, so then they needed to ask someone else to copy those files, every time that needed to be done.

This of course lead to a so called ‘management hell’, where you needed to allocate some decent time doing what was needed for your tests to still run, everywhere they needed to run. And this is just one example of a set of artifacts (in this case the driver files) that might be needed for the tests to run, apart from the tests themselves.

To solve the above problem (and any similar ones), a better approach is to store any such artifact that your tests need as part of setup, teardown or reporting, directly in the code repository where all the tests are. That helps with having only 1 place where you need to make any updates in case those artifacts require it. But also, because the repository itself is a folder that the tests inside it have access to, they will always have access to those artifacts. There will be no need to download them anywhere outside of the project, since from within the project you can reference them using a relative path. And, for example, even if you have a script stored in a file which you need to invoke, you know where to find it, and you can invoke it programmatically (as part of your test setup).

Oh, and in case for some reason you do need to copy some artefacts to a machine where tests run, you can now do this programmatically, automatically. That copy-paste action (from code repository to machine) would be included in test setup for example, since we are talking about automation (which should involve no manual work to get those tests running).

Another example of an artifact that sometimes gets misplaced (you didn’t bookmark the link to it, it’s difficult to find in Confluence…) is the project documentation. You should always have documentation that tells anyone who wants to use the automation project: how to install it, how to run tests, the project architecture, and any relevant further information. The README.md file is a good place to store this documentation (which will be placed on the root level of the project). It allows markdown, so you can nicely format the content. And since it’s on the root level, when you navigate to the project’s location in Git, it actually renders and is displayed on the project’s home page, automatically. And, if you need to reference it from an external location, like a Confluence page, you can provide the link to the repository.

So yes, any files that are not actually tests but are needed by them can and should be stored in the automation project. This is for easier management, and being able to find those files. These can be anything from html, pdf, txt files, even to setup scripts. And, if you have a Maven project for example, you have dedicated ‘resources’ folders for such files.

Hope this helps. Thanks for reading.