Test-Driven Development — The way I learned it

Disclaimer: I’ve not taken formal training, nor have I read any official books or documentation around TDD. This blog contains information based on my practice and learning from colleagues.

What is Test-Driven Development

Test-Driven Development (TDD) is a practice in where you write a test before the implementation of the functionality. For each functionality or behavior, you do following in order

  1. Write method stub (so that your code compile)
  2. Write unit test
  3. Run the test and see it fail
  4. Implement the functionality
  5. Rerun the test and see it pass
  6. Repeat!


Testable Code

You focus on getting the functionality up and running when you write the code first. When you come back for writing the unit test, you tend to refactor a lot because you wrote untestable code and ultimately ends up spending additional time. Additionally, non-testable code tends to miss coding best practices. For example, see below implementation of a function “convert,” which converts amount in given currency to target currency making use of ExchangeRate client.

When you’ll go and write the unit test for the above method, you’ll notice two major problems with the implementation

  1. Instantiating ExchangeRateClient inline makes it impossible to mock it correctly.
  2. Instantiating inline will make it hard in the future to move to a different ExchangeRate client.

Missed Test Cases

Writing tests after the implementation leads to missing test cases, usually because you rely on code coverage. In most cases, the developer relies on test coverage to feel good about the functionality, while, in reality, it’s dangerous as it often leads to missed business-critical features. For example, in the above implementation of convert function, you can write only one test case to achieve 100% code coverage.

The above tests resulted in 100% code coverage, but if you pass a negative amount, code will behave incorrectly.

Being Focused and Organized

Following TDD makes your thought process clear and focused. You’re focused on an individual test case, and it’s implementation when working on a single functionality. Also, it reminds you to focus on the functionality/business use-case instead of writing tests for the sake of code coverage.

Developer Ramp-up Time / Getting Started Guide for the Users

TDD forces you to write unit tests for business/functional use-cases rather than code coverage. It then serves as getting started guide for the consumer of your code or ramp-up guide for the other developers. For example, take a look at the SqlExtractor test cases from the PocketETL library. It’s pretty clear from the initialization code on how to use SQL extractor.

While the following test cases show, the code is resilient to SQL injection.

When to follow TDD

  • Long-running project: If you’re a professional working for an IT company, you’re are likely working on a long-term project involving multiple developers contributing together. You must follow TDD to make sure you’re covering all business cases/assumptions. Also, it gives confidence in refactoring the code whenever needed.
  • Libraries: If you are working on a library to be consumed by other developers, the right set of tests is vital to convey your intended usage and assumptions to the consumers. Also, it serves as your getting started guide saving multi-week effort on your part.

When NOT to follow TDD

  • One-off or small projects: For example, the project in a school, or personal website with your professional background.
  • Working with unfamiliar language: In my experience, it’s hard to follow TDD while working in a different language as it becomes hard to assert certain behaviors, and you tend to go deep into implementation details.

TDD in Action

Let’s implement the convert function for the CurrencyManager, which converts an amount from one currency to another. Let’s begin by writing the stub class and method before we get started. I’m going to assume that current exchange rates are provided by ABC source. I’m going to assume that ABCExchangeRate class is already implemented, which provides the current exchange rate from ABC source.

Now let’s write a test case. I usually start with a happy case. Remember, we don’t need to worry about the implementation yet. Consider the convert function as a black box and focus on what output it’ll produce for specific input.

Run the test and see it fail. Now it’s time to write the implementation and focus on getting just this case running. As I start writing the implementation, I realize I need ABCExchangeRate object to get the exchange rate. Since the exchange rate changes frequently and it’s a unit test case, I’ll need to mock it. For which, I need to dependency inject it as making the object in line will make it hard to mock. Let’s make those adjustments.

Let’s write another unit test for validating input.

The test failed with an error that the exception was not thrown. Let’s write the implementation now.

And now the test pass.

Reverse TDD

Writing implementation before tests are what I term as Reverse TDD. Having gone through the whole blog, you must be wondering why reverse TDD? Well, it’s essential for refactoring or making changes to the well-established implementation and set of unit tests. In long term projects, refactoring and making specific changes in line are bound to happen frequently. For such a scenario, I prefer to do reverse TDD. This way, you identify the impact of changes to existing functionality upfront by looking at the failing tests and determine if unit tests need adjustment or inline implementation is wrong.
Let’s see Reverse TDD in action and make changes in our CurrencyManager. Suppose your business decides the minimum amount supported (maybe because of the currency conversion fee). The new requirement is to make the minimum amount to be 10 instead of 0. Let’s make the code change first and run the tests.

Now you’ll notice that a happy case unit test will fail.

This way, you realized which functionality is impacted, and you can make a call, whether it’s failing for a valid reason. Let’s correct the happy test case.

Now all test cases will pass. Finally, it’s time to add a new test covering new functionality.

TDD Best Practices

Below are some best practices which are useful in general, or I wish someone told me as the beginner.

  • When writing unit tests, treat methods under implementation as a black box. Don’t worry about the implementation detail and focus on the expected output on the given input.
  • Force yourself not to write the implementation first.
  • Do not treat code coverage as success criteria for writing the tests.


TDD is a vital development tool that every developer should leverage. TDD helps you think from a customer’s perspective and forces you to work backward from the customer’s requirement. A well-written set of tests gives you confidence in refactoring code and usually results in uneventful code changes. TDD at first might seem time-consuming, but trust me, it’s going to save a lot of time down the line.