Hidden TDD Benefit: Bookmarks

TDD is often mentioned for its benefits in code quality such as following DRY, YAGNI or other clean code standards. Today I want to talk about one overlooked benefit that has helped me countless times.

Working in an open office has a few benefits but many downsides as engineers. Tips such as pair programming or listening to music help a little but even then there are always distractions. In addition to distractions, there are always times in your workday when you need to stop working for some amount of time. We all have to eat at some point.

With the constant problem of starting and stopping at least a handful of times a day, how does TDD help?

Bookmarks

TDD offers one very powerful advantage, a bookmark. You see, TDD is split between 3 phases usually referred to as red, green, refactor. Each of these three states can be easily discovered by running your test suite. By making our feedback loop as small as possible it also reduces the amount of information we have to keep in our heads at once.

Now generally, TDD expects you to write your test just before it fails. This is so that you do not preemptively write code for a later feature. However, we can take notes on what tests we will probably want to write later. That is, a comment or a test case that has no code but a failing assertion. We can use the name of the method to know what we need to write when we get there. This acts sort of like chapter titles.

Before we begin we do have to do some setup work. Depending on your preferences and test runners you can choose between;

• Writing empty test methods that fail
  • Only recommended if you can stop your test runner on the first fail ( for python and pytest you can add the -x flag )
  • If you can not stop on the first failure you will have to keep scrolling up to get the error logs and it's not fun
• Writing notes in code or on paper for your next tests
  • If using this method I like to write the method how it would look but just comment it out so I can pull it in later.

Note that I recommend configuring your test runner to re-run your suite on file change. For python I use pytest-watch, karma has a configuration for it, I believe jest does as well.

Take a break at any time

Now that I have a set of test cases written down I have a few benefits. The first is, until all these test cases are done I know exactly what I am doing. And at any point, I can take a break and come back and know exactly what I need to work on next.

This plays out in two ways depending on your choice of commented test case notes or failing empty test cases.

Failing empty test cases

This is my preferred approach.

We start by writing test methods with descriptive names and just a single failing assertion.

def test_missing_user_auth_raises_401():
    assert 0

An example that has a clear description but no code. We can write as many of these that we come up with ahead of time. Noting that we may change our mind later but that is fine.

Now, if we come back from a break and our tests fail because 0 is not true ( or the equivalent for your language ) then we know we are in the green or refactor phase and we can choose to refactor or write our test.

If we come back and our test is failing for any other reason. We know we are in the red phase and we need to add code to get our test to pass.

Finally, if all our tests pass it means we have finished all our existing test cases. At this point, we can probably make a pull request. ( or add docs and that good stuff )

Test comments

If you go the route of just writing comments the flow is similar but has a few differences.

If we come back from a break and our tests all pass then we are in the green or refactor phase and can pull the next comment out and write a test case.

If we come back and our test is failing, then we are in the red phase.

Finally, if our tests pass and we have no more comments we make that pull request.

With this, I have been able to work quite efficiently despite the many distractions of an open office.

Thanks for reading.