The 4th step in TDD

If you are doing TDD or not, your daily work is combined from a few repetitive actions. Each one has its own “methodology”, even if he is not aware of.

Yesterday I have been working on a bug from production. I created a test reproducing the bug, meaning I had a failing test — the 1st step in TDD.

While working, I found myself thinking about a lot of things in the same time: refactoring, trying to understand the existing code, how I make my test pass without breaking the others, how my tests should look like and so on.

I got into a SWIRL.

When I noticed that, I stopped and said to myself ”Shani, one of the reasons you like TDD is because it makes you focus better. Currently, you are not focused at all”.

So I decided to focus on just making my test pass, ignoring that others will fail. And on that occasion make sure they do fail.

If you think about this, I split TDD 2nd step into two:

1. Make my test pass

2. Make all the previous tests pass

Why I did this? Because I noticed thinking about those two together was mentally too much for me. (The number of objects an average human can hold in working memory is 7 ± 2, I think for me is just 1 😅)

So here it is, after a search for the relevant entry point for my code, I added one line with hard-coded values relevant only for my test. Happily, Now some tests are red, time for the hard part: making it all work again.

If my changes didn’t cause any tests to fail, it means I didn’t have tests testing different scenarios that were affected by my change (besides the bug scenario). Since I added one line with hard-coded values it probably should break some tests. If that was the case I should have added some green tests before I changed the code in order to catch regressions.

Would love to hear your thoughts and about your personal methodologies.