I completely disagree with the accepted answer.
What you described is actually very desirable. The flaw in the thinking behind the answer is the assumption that the thing being tested is the code on the branch in isolation from other work, but that's not true.
You should be testing fully integrated code whenever you can.
In other words, the idea of "not the code that was intended" is wrong. Let's say that the system is tested and passes all tests. If it passes all tests with the code both that was committed by the first developer and also the code that was committed by the second developer, then that's great. You've just saved an extra test cycle to tell you that the code from both commits is fine.
If the code from the second commit causes the tests to fail, then that's great too. You've just saved an extra test cycle to tell you that the code needs a fix.
If the code from the first commit causes the test to fail, you've learned what you needed to know regardless of the second commit.
If the code from the integration of the first and second commit causes the test to fail, then that's great. You've saved an extra test cycle to tell you that the two developers need to work together to solve the integration problem.
Essentially there is no drawback to testing the second commit as well as the first. I do not understand where in the industry this idea came from from a technical perspective. The only reason I can think of that someone would care is because they want to be able to apportion blame to a particular developer for a failed test. And that sounds pretty dysfunctional to me.
All you're doing with this type of development and branching strategy is making the development process slower and more expensive.