Search code examples
tdd

Sequence of your commits in TDD?

so my question would be that how will sequence of commits look like when we follow TDD

so in case 1, we will have a guarantee that our build will not fail and it will incrementally add features to your project. but in the case 2 some commits will bring build failures. though the second demonstrated TDD perfectly I feel that case 1 is also perfect TDD. wanted to know opinions & industry standards?

case1

1.code and test for scenario 1

2.code and test for scenario 2

case 2:

1.test for scenario 1

2.code for scenario 1

3.test for scenario 2

4.code for scenario 2

Solution

  • so my question would be that how will sequence of commits look like when we follow TDD

    TDD, for the most part, doesn't really say much about this.

    The usual practice is that you never share changes when tests are RED; the reasoning here is that, typically, even a single test failure causes the build to fail, which means that your well intended commit of a failing test blocks other fixes and features that come behind you from being deployed into production.

    Now, if the commit of the broken test doesn't fail the build (hopefully because the test is deliberately excluded from execution, and not because our build pipeline is lenient), then it might make sense to commit failing tests.

    When I am building out a branch in git to show how I might TDD something, then I do commit broken tests so as to clearly demonstrate each of the RED/GREEN/REFACTOR tasks. But these demonstrations differ from the above cases in two important respects

    • They aren't shared; nobody else is going to get blocked when they merge my changes
    • There's no pipeline enforcement that "all of the tests pass", because there is no deployment at all.

    Test Commit/Revert (TCR) is a different coding habit that is somewhat related to TDD. The key idea is that, when you run your tests locally, you get one of two outcomes

    • All of the tests pass, therefore your latest changes are automatically committed (usually with a general-purpose commit message)
    • Any of the tests fail, therefore your latest changes are automatically discarded

    ... which means that you can't commit a test without the code to make it pass.

    One of the use cases where tests without code really suck? git-bisect; if I'm trying to track down a weird problem between two commits, your "the tests don't pass" commit between my good commit and bad commit may end up making a lot of extra work for me in a context where we are already off the happy path.