Get startedGet started for free

Test-driven development

1. Test-driven development

Welcome back! Now, we'll discuss a new way to think about tests.

2. Test-Driven Development

So far, we've written tests after writing code. But many engineers write tests first. This is called Test-Driven Development (TDD), a technique where tests guide the design. It is applied by writing tests before writing code. TDD is an essential skill for software engineers. So, why practice TDD?

3. Benefits of TDD

TDD offers many benefits, especially as projects grow in complexity. Here are a few: Turning requirements into tests helps clarify what's needed, improving understanding before coding even begins! TDD improves correctness by instantly verifying changes. Letting tests guide implementation leads to cleaner, more modular, better-structured code.

4. The Laws of TDD

Robert Martin, author of the foundational books Clean Code and Clean Architecture, defines the three laws of TDD as follows: We must write a failing test before writing any code. We must write the shortest test possible that will fail, or fail to compile. We must write the smallest amount of code possible to make the failing test pass. Following these steps completes one TDD cycle. Engineers often develop software through many such cycles.

5. Testing for palindromes

Let's see TDD in action. Suppose we need a method that checks if an integer is a palindrome, meaning, whether it's the same when reversed, e.g. 12321, 0, 3333).

6. Write a failing test before writing any code

We write a basic unit test, but it fails to compile because `isPalindrome()` doesn't exist yet. But now we know what isPalindrome() needs to do! TDD is like leaving notes to our future selves, making sure we don't forget any requirements.

7. Write minimal code for the test to pass

Next, we write just enough code for the test to pass, but nothing more. Our test now passes, but our feature is not complete. We must do another cycle of TDD.

8. Write another test

We write another test, this time requiring the method to return `true` for a palindromic number. It fails, because the existing implementation always returns 'false'.

9. Implement the method

We now have no choice but to implement the method. We iteratively grow our inverted number by multiplying it by 10, and adding to it the last digit of the starting number. Recall we can obtain the last digit using modulo 10. Both our tests now pass. Using two cycles of TDD, we have implemented our feature.

10. Bugfixing with TDD

TDD is also great for fixing bugs. Suppose, we learn that our method is saying -121 is a palindrome! This is wrong, because we can't reverse the minus sign. We write a failing unit test that demonstrates the bug.

11. Bugfixing with TDD

We fix the bug by first checking if the number is negative. Then we save the fix along with the new test, giving us confidence the bug is resolved and guarding against future regressions.

12. Let's practice!

Let's now practice thinking about and writing code with tests first!

Create Your Free Account

or

By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.