Reality is complicated. If the code on a feature branch passes all the tests, it does not mean that the build will not fail when it is merged to a stable mainstream branch. Both of the popular branching strategies mentioned in the GitFlow and GitHub Flow section assume that code merged to the master branch is always tested and deployable. But how can you be sure that this assumption is met if you did not perform the merge yet? This is a lesser problem for GitFlow (if implemented well and used precisely), due to its emphasis on release branches. But it is a real problem for simple GitHub Flow, where merging to master is often related with conflicts and is very likely to introduce regressions in tests. Even for GitFlow, this is a serious concern. This is a complex branching model, so for sure people will make mistakes when using it. So, you can never be sure that the code on master will pass the tests after a merge unless you take some special precautions.
One of the solutions to this problem is to delegate the duty of merging feature branches into a stable mainstream branch to your CI system. In many CI tools, you can easily set up an on-demand building job that will locally merge a specific feature branch to the stable branch and push it to the central repository if it passed all the tests. If the build fails, then such a merge will be reverted, leaving the stable branch untouched.
Of course, this approach gets more complex in fast paced projects where many feature branches are developed simultaneously, because there is high risk of conflicts that can't be resolved automatically by any CI system. There are, of course, solutions to that problem, like rebasing in Git.
Such an approach to merging anything into the stable branch in a version control system is practically a must if you about going further and implementing continuous delivery processes. It is also required if you have a strict rule in your workflow stating that everything in a stable branch is releasable.