TDD introduction

Quick disclaimer

This blog post covers the theoretical part of TDD. For a practical example, I’ll be uploading a video in a separate blog post and provide a link to it.

What is TDD?

To put in simple terms, TDD is a style software development where we start from writing a failing test first, then writing bare minimum code to make it pass and then doing refactoring if required.

Pros of TDD

• Improves a programmer’s productivity
  TDD helps to make the programmer productive by forcing them to focus on the small segment of the code. Also, because we start with small tests and evolve both the tests and code on our way, it becomes easier to debug the issues as the test themselves reveal the reason for failure.

• Helps to create a better design
  Because in TDD we start by writing the tests first and refactor the code once the test passes. Starting with a failing test helps because that way it forces us to think about the consumer code first. If something is hard to test, usually it’s usually due to bad design. Also, the continuous focus on refactoring forces the programmer to think about the design.

• Helps to get in the flow
  TDD helps the programmer get into the flow and keep them motivated. The reason being because we are focusing on a small problem, it doesn’t place too much load on the cognition. Also, because of the dopamine rush of seeing the test pass, it gives a motivational boost to the programmer to keep going and enjoying the process.

• Gives programmers confidence in their code and freedom to do merciless refactoring
  The tests act like a safety net, so in case the programmer does any mistake the tests give them immediate feedback. Also, since the programmer started with the failing test first and not the other way around, they are confident that if anyone removes their code or changes the implemented then the tests will fail. This gives them confidence in their code and they know when all tests pass that the requirements are completed.

• Helps them embrace the fail fast or early pain philosophy
  TDD makes beginners uncomfortable, but it’s very important. Lot of things in XP are uncomfortable because the pain areas are addressed first rather than later. Once a person understands the reasoning behind this and experiences positive results, it makes easy for them to understand why agile works so well.

• Works your brain’s right hemisphere
  As per the Pragmatic Thinking and Learning: Refactor Your Wetware Book by Andy Hunt, it forces us to use the bran’s right hemisphere. The reason being we use synthesis i.e building things opposed to analysis using TDD to build the design. Working or training your right hemisphere is very important because it trains your intuition, which is required to become an expert as per the book.

• Goes really well with pair-programming
  TDD can be combined with pair-programming. In this case, one person writes the failing test and then passes on the keyboard to the other person who writes the code to make it pass. The refactoring step requires collaboration and can be done by either of the parties, but it’s desired that they rotate the work amongst themselves.

• Live documentation
  The tests serves as the live documentation of the code. The reason being the tests are tightly coupled to the code. So they scream the requirement to reader. Thus, there is no need to maintain a separate documentation for the code.

Cons of TDD

• Requires patience and discipline
  TDD takes some time for beginners to adapt. TDD is a mindset and requires discipline. It takes time, effort and deliberate practice in-order to make it a second nature and to reap out the benefits.

Common mistakes people do when doing TDD?

• Not following the discipline properly
  If you are not following the cycle of TDD i.e red, green and refactor in the given order then you are not doing TDD. You need to write a failing test before making it pass.
  Similarly, you need to follow refactor step else TDD won’t lead to a better design.

• Not writing minimal code to make the test pass
  Good programs solves the problem, great ones prevent them. Any code that you write is a liability. Therefore, we should write bare-minimum code to make the test pass.

• Not giving it enough time
  If you don’t practice something, you won’t learn it. And if you don’t learn it, you won’t get the benefit out of it. TDD requires consistent time and effort.

  If you feel it’s not making you productive, you haven’t given it enough time. Eventually with time, you will discover that it makes you develop programs much FASTER and with much EASE.

• Not doing it in the front end
  TDD can be applied to both front end and backend. Usually if something is hard to test, it’s because of bad design. For e.g. in React’s world common business logic can be extracted into hooks. That way unit testing them becomes easier.

  With React testing library you can mock the components being used in the component under test. That way testing them becomes easier. Again if something is difficult to test, it forces us to think about our approach. Taking the same react example, if we start with small components then it will make testing easier.

• Not giving the test code the respect it deserves
  Your tests are your live documentation. They scream the use-case/requirement to the readers. Therefore, it’s important that you treat them with the same respect, if not more than what you give to the production code.
  That include ensure you don’t have code duplication in your test. The only exception to this rule is test readability.

  If for any reason you have to chose between code readability and code duplication in terms of tests, then always go for readability.
  Because reading and understanding code is more expensive. Also, I would recommend you to use the arrange, act and assert way of writing the tests. That makes it is easier for read to differentiate the data-population part, the code in action part, and the assertion part.

Conclusion

I can write so much about the topic but I don’t want to overwhelm my readers. I hope by now, you have some idea about TDD.
In case you are someone who thinks they are doing TDD, I hope you are able to identify some mistake you are doing or are at least aware of the common ones that people do. This way you will be response back whenever someone say that TDD isn’t working for them.