My takeaways from Kent Beck’s Test Driven Development — Part I

I have been reading Kent Beck’s Book: TEST-DRIVEN DEVELOPMENT By Example for some time and am writing my takeaways from it.

Before saying anything, I would like to answer the question Why? Why TDD at first place? It’s a very BASIC question, but it’s a general observation that people who often ask WHY often tends to stay in the right direction rather than going down the rabbit hole without a sense of purpose at all. Hence, whatever your job may be, whether it’s business, programming, following the rabbit to the hole or what not, never be afraid to ask WHY. Now you’re wondering why I am talking about the rabbits when I came here to talk about Test Driven Development. Yes your’re asking the right question now. WHY.

So why?

1. It makes your code predictable. Mr. Beck starts with an example where an external client comes to the engineering team who have been handling money in Dollars, if they code could handle multi-currency. And no one could confidently tell the client YES Or NO. Had they had tests for the code, they would know the answer.
2. It makes extending the code easier. When you’re extending or refactoring a code, if you don’t have tests, the confidence level that you’ve not broken something is quite low. The idea is that even if you don’t have tests when you try…