The One Thing Every Junior Developer Needs to Know About TDD

Why test driven development is vital for high quality software



2 years ago | 2 min read

Imagine spending a full week developing your software, your best piece of art. One day after the release, many people are now experiencing bugs and crashes. Strange, but you’re full of energy and willingness to do, so you immediately start to fix those problems. Nonetheless, you soon realize that for one simple and innocent bug you are now forced to rewrite 80% of your code.

And the cycles continues, the initial one week of work is now doubled, and then a month, six months, a full year. Your software is now unmaintainable. You have now 2 choices:

1) Rewrite the entire source code

2) Abandon the project

Pretty drastic huh? But that’s how most inexperienced programmers write software, quick and dirty. And since the world has more junior than senior developers, you’ll often find this pattern even in some big companies.

Bad development

This image is essentially explaining what I’ve just told you. It’s called the software development curve, and it shows how development speed is correlated to time.

In the beginning, you’re very fast at developing and improving your software. But as time goes on, it will become exponentially slower and slower… and slower.

What if I told you that there’s a way to flip this curve?

High quality software

High quality software development

With good design patterns and standard principles, you’ll be able to build better and more maintainable software. There are many tools that can help you achieve this, and TDD is one of them.

Test Driven Development, as the name suggests, is about making tests.. right? Not much, TDD is a design process that helps you think before you write.

It’s true, you’ll eventually write tests. But tests are an excuse to think about the structure of your code. The development process is very simple:

  1. Write a failing test
  2. Write just enough code to pass the test
  3. Refactor the code
  4. Repeat

As you may have noticed, testing something that you didn’t even write is forcing you to think about the behavior of the code. In fact, even if you don’t even notice, you’re designing the software.

Writing tests will force you to view your code as the “consumer”. And because of this, you’ll handle all the edge cases (that you would have never think about) and completely remove every small bugs.

Of course, TDD alone is not the solution to every problem. But combined with other practices like good documentation, consistent coding style and SOLID (or many others) principles, it will definitely help you building great high quality software.

Why you should use TDD

  • Easy process
  • It forces you to think
  • Continuous refactoring
  • Evolutionary design (instead of big design up front)
  • Prevent bugs

Practice, practice, practice

Practices makes it perfect. If you’ve never used TDD, try out some coding katas. There are a lot of problems to solve, tailored to every experience level.If it’s the first time you’re using TDD, you’ll soon realize how difficult it is to think in “reverse”. Practice, practice and you’ll be used to (trust me, it will be worth it)

Explore more TDD


Created by








Related Articles