TDD way: Is this the way?
I do TDD, but not religiously. There are moments, where my brain is efficient and tells me, write this logic down NOW, otherwise I will take a 45 min break until I provide you with the same solution. So I respect that, and at least write the logic in terms of comments. But does this mean I not TDD'ing right, very likely. Because this would clearly influence how I write my test cases.
TDD is hard!
TDD is not just hard to put in practice but also there are moments sometimes you question the value of it. So I am gonna tell a short story. Which probably does not make much sense, cause I suck at story telling.
Bear in mind, I am neither a TDD pro like @Javier Lopez nor an author like him.
☀️☀️ And so the story begins 🐣🐣
In a land far far way, there was a company called TDDole, where teams were built on trust and mutual respect. And here is a short episode on what happened at TDDole.
PM: Good day devs, we need to implement this new feature. Could you please estimate it?
Devs: 1 Sprint, take it or leave it.
PM: Sounds good!
Team: Breaks the feature into smaller user stories (cause that's a reasonable thing to do)
Dev-α: I am gonna pick the user story BPM-1
Dev-α: I understand as part of BPM-1, I have to write a small function which does square of a number.
Dev-α: But as TDDian I will write tests first and the code later.
Dev-α: I have written every possible scenario as a test and now I have completely tested the method. And it only took me 2 hours 👌🏾
-- Two sprints later ---
Devs: Hey PM, feature can be considered done now and it's in staging.
PM: Great, I will have a look and QA will test as well.
PM: All good! Let's go to production.
-- One week later, on a Friday afternoon at 4 PM ---
PM from another mother: Yo, we are having strange issues, the values we see are complete whack. And we think your component is messing things up.
Recommended by LinkedIn
PM: I shall ask my team to check it out.
Devs: I am sure the bug is from other component. Our code is as pure as Heimdall.
Senõr-Dev: Hey Dev-α looks like the issue is coming from this piece of code, looks like you wrote it last sprint.
Dev-α: Alright, the bug is happening cause I am squaring the number where I should have just multiplied by two.
Dev-α: Yo PM, the fix is instead of x^2 I have to do x*2. And it will fix it.
PM: So, it's a 1 minute fix 👏🏾. I knew you guys were good 🙌🏾.
Dev-α: Well I have to fix the 20 test cases I wrote so that's gonna take an hour.
PM: Can you not just ignore the tests for now?
Dev-α: No, I swore on TDD bible in front of Martin and Kent and I don't wanna go to software hell.
PM: So we are not gonna release the fix today?
Dev-α: Nah!
🌖 🌗End of story 🌘 🌑
Alright, I made TDD look bad here. But any sensible person would expect a fix of x^2 -> x*2 would take few minutes at most. If Dev-α did not practice TDD he probably would not have written so many tests (or probably none). Of course TDD does not force you to write too many tests, but you end up doing so.
We always refactor our code, ALWAYS, cause we become better developers.
But what exactly are we gaining from TDD?
Well, consider this; In future Dev-β realises code from Dev-α needs a refactor. Thanks to the tests, Dev-β can refactor the code and not be worried of breaking the functionality. We always refactor our code, ALWAYS, cause we become better developers. And to know that you can make something better and not be worried of breaking it, is a luxury, and TDD is the price you pay.
TDD also helps you do what you are supposed to do, not what you would like to do. It guides you in building smaller blocks, and in building testable components. At the end of the day you deliver something that works in most simplest way possible.
Final notes:
I am not sure if my point came across with this post. I believe I am better at programming than writing articles. But I wanted to express how I see TDD and why I think the price you pay is worth the outcome. At the end of the day, as Javier Lopez says, do what you like. We are programmers not police 😉
I apologise for lack of pictures in this article.
Software Engineer: Front-end Web Developer. Cofounder of Catwizad and LingoStand at Catwizard Inc
3yBharath thanks for such an illustrative and fun example! It really gives you a good reason to practice TDD! 👏👏😜
Senior Software Engineer at Atlassian
3yHey Bharath, it was nice reading this. Seems like you´ve decided to go down the fun path on LinkedIn lately. I love how fresh your writing style reads 🙂 I´m not gonna get myself into the tech discussion here. I think you folks have already had an interesting one already. However, I have to say I was a little confused by your post. I could not clearly distill the message you wanted to convey here. For most of the post, it felt to me like you were advocating against TDD or, at least, in favour of a more on-and-off practical vision to it. But then, by the end (and in your comments here), it seems like you actually advocate in favour, just maybe not 100% of the time... while not being super clear on the conditions to hop on and off it. I believe, say, 80% TDD is what you were trying to "sell" here, but really struggled to see it clearly. And I think I did struggle because, in my view, you did not follow a sort of clear straight line from start to end in your writing and, instead, moved along in some back-and-forth way that added confusion to my brain. Having said that, this may just be me and my lack of sleep today to attend the #tarugo21, so please ignore me if I´m talking nonsense :-D
Senior Java/Kotlin Engineer | TDD practioner | Testing expert
3yHey Bharath, kudos for the write-up! In your example, how dev-alpha knows that the requested change actually works? How can he prove this? Tests (not exclusively TDD) are that proof. If not the tests, how the poor dev-alpha could be sure that the code is working? By checking in on the running system. When having tests, he can do two things: * go the TDD way: change 20 tests with the new expected value, watch them fail, fix the production code, go green and deploy * go what I call mutation-TDD: make a bet which tests will fail and change the production code. If you won the bet - fix the tests. If you lost the bet - cover the production code with minimal tests that will go through the code you want to change. Then rinse and repeat The value of tests is that they provide you with proof that you really did the change and the change is what you really expect. The change from red to green (or green to red in case of mutation TDD) is this proof. Regarding your statement that when doing TDD you end up with many tests - this is not the result of applying TDD. If you have blind confidence in your code or you don't want to have repeatable and automated checks of your code, you don't need tests. But if apply the rule of limited trust in yourself and you want to automatically verify the behaviour (with all weird edge cases that we know will happen 15 minutes after the production deployment), then you need a sizeable amount of tests. This is not something new invented by a generation Z agilist - there are vast testing theories and practices already invented as early as in the 70ties that can give you many viewpoints on how the software should be checked.
Principal Engineer en ThoughtWorks
3yHahahaha, do whatever you want!. At that point no one follow listening me. Thanks for sharing, it's great to see your point of view and your experience. Tdd is a tool, we need to understand when to use it (I prefer to use it almost all the time).