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.

SWIRL IMAGE

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.

FOREST IMAGE

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.

Latest comments (2)

Collapse
 
mcsee profile image
Maxi Contieri

Wow ! Love it. going for the 4!

Collapse
 
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.