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?

closed as too broad by gnat, Robert Harvey Apr 29 at 17:46

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    I've done my best to tidy this question up a bit. Making the question clearer will lead to better answers. Can I suggest you have a look at the last paragraph so you're asking one question not 5? – Liath Apr 29 at 10:47
  • Your question lacks a problem to be solved. Look at your last paragraph, remove anything that asks "is this OK," "is this acceptable," or "what is considered best practice," and ask a specific question that's related to a software development problem you are currently having. If you don't know where you're going, any approach will get you there. – Robert Harvey Apr 29 at 17:45

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.

  • The thing is that was created PR with a lot of Unit tests for many components. Main argument for splitting is that tests can crash CI deploy. – thousandsofraccoons Apr 29 at 10:47
  • 1
    I'll try to update my answer, however if if your tests are crashing your CI then that's a problem. Make sure they're high quality tests! – Liath Apr 29 at 10:48
  • And if we split unit tests into PRs - we can quickly reset it back in case something will go wrong. – thousandsofraccoons Apr 29 at 10:51
  • 1
    Would you rather have failing tests which highlight bad code or failing code which doesn't break build? The point of CI/Tests is to break if something goes wrong. Backing out your tests doesn't improve the code, it just ensures you don't know about it – Liath Apr 29 at 10:52
  • As I mentioned above make sure your tests are high quality. No external dependencies, repeatable, atomic, and all those other good unit test characteristics – Liath Apr 29 at 10:53

Not the answer you're looking for? Browse other questions tagged or ask your own question.