DEV Community

Shani Fedida
Shani Fedida

Posted on

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.


Photo by Cassidy Kelley on Unsplash

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.


start from a failing test and then make only my test pass

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.

Top comments (2)

bitschupser profile image
Alex Rampp

Thx for sharing this methodology.

I also sometimes get overwhelmed. Especially when doing structural refactoring and suddenly many tests fail. Sometimes it's helpful to narrow down the scope ans say "now I just make this 1 out of 20 failing test pass" and then "I make the next 1 out of 19 failing tests pass" and so on. Often after doing this a few times I recognize a pattern which broke these tests and can move on more quickly.

mcsee profile image
Maxi Contieri

Wow ! Love it. going for the 4!