Unit tests branch best practices [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 1 year ago.

Improve this question

I'd like advice about on the best practice for Pull Requests organizing on middle size project. Especially relating to Unit Testing.

Currently we create branch for each feature, what is practically good.

Is it acceptable to send PR with random Unit tests (do not follow feature-model)? Is it okay to save time on creating tickets, branches and just do a PR with pile of files? Or One feature branch - one unit test branch is essential in long term?

Answer 1

Unit Tests should be submitted in the same PR as the code they test. Or, to phrase it a different way submitted code should not be accepted without an agreed* level of unit testing.

Going back and adding tests later is a myth, it never happens. To use a popular analogy you wouldn't ask a car mechanic to replace your brakes and then book a further appointment for them to test the brakes were fitted correctly!

The only exception to this is when you are adding tests to a previously written piece of code (I know I said it never happens in reality but maybe it's pre-refactor or something). In this case you can submit tests in a PR without code. However that is because there's no code, not because the two have been split out into different PRs.

PRs should always be as small as possible. Smaller PRs mean short branches, fewer merge problems, less change, and lower risk. If you have more than a day's worth of work in a PR then it's likely to be too big.

It's also worth noting that Unit Tests make PRs easier because the reviewers can see the passing tests/scenarios rather than trying to visualise how the code will behave in certain scenarios.

*the level of Unit Testing required will depend on the team/project.