Should unit tests run on every git branch?

Question

I am new to repo management / continuous integration.

I designed a repo in the following way

PROJ
 |-src
 |-include
 |-lib
 |-config
PROJ_Unit_Tests
 |-src
 |-config
PROJ_Doc

When I now do continuous integration, i.e., running unit test on the build server, should they run on every branch or only on the develop branch?

If they only run on the develop branch and a feature branch going on for long, I am afraid that the developer is pushing changes to his feature branch which would actually fail the build. On the other hand, if a feature branch deactivates functionality of the develop branch, then the programmer has to manually disable to corresponding unit tests.

• WarrenT: This concept should not be applied beyond a specific shared team repo, or not to repos below a certain layer. Developers should still be allowed to have personal or "work-in-progress" repos, where some branches may be experimental or incomplete. The ability to easily create experimental branches was a fundamental goal when Linus Torvalds designed git.
• Shivam Sahil: How do you indicate UT in all branches? like in yml file: branches: [*] ? Just curious

Answer 1

Run your unit tests on every branch. How do you know your code is actually working as expected otherwise? This goes the same for any other tests you may have.

You say it yourself right here, "If they only run on the develop branch and a feature branch going on for long, I am afraid that the developer is pushing changes to his feature branch which would actually fail the build".

The latter problem you're hinting at is up to the developer to address. It is their responsibility to update the tests alongside the features they are developing.

On top of all that, investing in actual continuous integration, as suggested by your reference model, will alleviate some of the pain of feature branches straying to far from the development branch or other feature branches.

Answer 2

Should unit tests run on every git branch?

This one is an easy one. The main point of doing continuous integration is to detect errors as early as possible in the build process.

From this it should be clear, that you should

a) run a testsuite on every branch of your code

b) do not allow checking in code, which neither runs nor passes all tests

This is the minimum requirement for checking in code and doing successful continous integration

tl;dr

yes

---

Offtopic:

I read the other day an interesting article published on a well known german IT-Portal (Heise.de) from a well known german consutant Eberhard Wolff about branches as a contradiction to continous integration in which he argued, that developing branches is in principle a violation of CI, since you separate code for some time and detect conflicts only when merging branches back in. Branches could only be tested in isolation - which is obvious, because of their nature. He votes for one main branch and feature toggles for disabling new features on production. Of course this is not always a feasible solution (he clearly sees that toggles are not without a cost). Sometimes branches are an alternative. But he recommends really shortlived branches.

Here is the (german) article.