Automated tests close to code

Hi there!

Where do you prefer keeping your automated tests - same repository as application code or separate repository? Why?

In the past, I would usually keep API or UI tests separately from code, but it always meant devs having hard time maintaining or extending tests. In my new project I want to try different approach and include tests in same repository as application code. Please share your experiences :slight_smile:

I’ve done both. I like test code living in parallel with the application code. We already had this paradigm for unit and integration tests. Extending it to functional/end-to-end tests seems like a no-brainer in hindsight.

The biggest advantage here is that tests should align with the current code implementation. There’s no cross referencing between two repos to figure out what version of the tests need to be run against a particular version of the code. This in turn simplified our CI pipeline - only one repo to keep track of, check out, build, and run tests against.

Another benefit is that by pushing the code closer to code developers work with, it encourages them to take some ownership of the functional tests. We don’t gate on end-to-end tests since we’re not mature enough to have requirements/contracts specced out to the point where they can be updated at the same time as the features are built/updated/etc, but seeing the functional tests fail encourages folks to do that.

2 Likes

I agree with @ernie and for the reasons stated. Additionally, anyone would be able to run the suite of tests to get feedback on new and changed code. I think of it as running a regression very, very frequently.

Also, this works, as you may have experienced @vilkg, very well for API projects!

Joe

I agree with everyone here. Having the same repo for both application and test code does have its advantages. That being said, there have been cases where I preferred maintaining them separately. This is especially when developers follow different coding practices and PR rules and the test team follows something different due to various reasons (Especially when the development is done by a 3rd party vendor/outsourcing company and testing is done by in house team).

No matter what the process is, I do think automation code should be treated like application code. It should have its own stories, review process and cadence.

1 Like