When should I commit and push in Test Driven Development? [closed]

Question

My question regards TDD and when should I commit or push changes?

I'm wondering is it fine to push the code where some values returned by function are still faked or implementation is obvious to pass the test but interface exists. In other words may I push the code before redactor? Or otherwise: may I push the code which does not change "interface" but does not do actually work yet?

I'm not telling about unit tests but more some integration/acceptance end-to-end tests where e.g. I'm getting some data from tool A, send it to tool B and check is database record was created. Implementing such tests is often time consuming and contains many asserts at the end but pushing early version of code allow another team member to work based on our part of work.

Thank you for answering this question in advance.

Answer 1

A development workflow is always some consensus between the developers that it involves, so there are no fixed rules in play here. You need to coordinate with the other developers to figure out what works best for you.

That said, my personal approach here is that you should never break the remote master. Instead, commit and push to a branch as soon as you have something that compiles (even if the tests fail), and then merge with master once your tests pass, i.e., only push working code to master, but have your non-working tests on a branch whenever you like.

If you have any kind of continuous integration system in place, this workflow ensures that you never end up breaking your CI build by pushing a bunch of failing tests to the branch that the CI system is going to pick up and test.