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.
So if you think about this, I split the 2nd step of TDD into two:
- Make my test pass
- Make all the previous tests pass
Why I did this? Because I noticed thinking about those two together was too much for me, mentally. (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.
