Skip to content
markdown guide

I totally agree with Leighton on the book recommendation. "Test-Driven Development by example" from Kent Beck is "the Bible" for TDD. It's great to learn the fundamentals. The fundamentals are important. As Leighton already said: get "Red-Green-Refactor" loaded in your brain.
Code Katas, like the mentioned "String Calculator" or Uncle Bob's "Bowling Game", are good to learn the cycle.

BUT: I think there are some very important techniques you need to know, before you can make use of all the TDD benefits.

Dependency Injection:
It's nice to test your code. But if you want to end up with code that is well designed, you need to understand the concept of dependency injection. If you are comfortable with .NET I recommend this book. For me, this is one of the key concepts for testable and maintainable code.

Know your tools:
You should choose a testing framework. I am a .NET-guy. So I use xUnit.NET a lot. Another choice could be NUnit. These two are the two "big ones" in the .NET world. Of course there is also MSTest, but I could never get used to it.

The next important tool, in my opinion, is an isolation framework. My favorite one is NSubstitute. It is simple to use and creates "easy to read" code.

And in the end your programming language and IDE are tools, too. You should choose a language, that supports unittests in an easy way. Most modern languages are quite OK for that. But, as usual, some of them are more "test-friendly" than others. I checked your profile and it looks like you are familiar with C#. I think it is a reasonable choice.

After you tried TDD on a real project, I would love to hear how it went. Maybe you can join the discussion about the problems with "real world TDD".


Yeah ok thank you,i started looking at dependency injection weeks ago...
Yeah i will definetely join the discussion =D


If you're an absolute beginner with TDD, and you're looking to get a feel for how it all works. I'd recommend getting familiar with the Red, Green, Refactor cycle.

Red: Write a test that fails.

it('returns 3 when given 1 and 2', () => {
  expect(calculator.sum(1, 2)).toEqual(3)

Green: Write the minimum amount of code to make that test pass.

class Calculator {
  sum () {
    return 3

Refactor: Clean up the code you just wrote, if you need to.

then do it again...


it('returns 4 when given 2 and 2', () => {
  expect(calculator.sum(2, 2)).toEqual(4)


class Calculator {
  sum (num1, num2) {
    return num1 + num2

Refactor: It's still pretty clean, so we won't.

Once you've got your head around that pattern. Have a look at something like this. Little, time-boxed, problems like these are great for building the habit of TDD.

An important thing to note here is that these examples are intentionally simple. Starting to write a .sum() method that just returns a fixed number doesn't make a whole lot of sense in the real world. But it helps to train your brain to start as simple as possible with your features and implementations. After a few runs through a few examples, you can just forget about starting that simple.

You can start working on these types of problems with just plain ol' JS and a test framework like Mocha or Jest.

If you're interested in a deep dive and you've got some spare cash, this is the book.


Thank you, the Red Green Refactor technique summarize it all... :)


For backend work TDD is essential to me, when I'm doing frontend it normally slows me down.

TDD is about creating a fast feedback cycle, no backend dev wants to run all their code just to test one piece. With web frontend work I'd rather be live editing the HTML, running test code in the console or hot swapping my changes.

For business logic TDD makes a lot of sense, don't use it where it doesn't make sense.

Classic DEV Post from Aug 23 '19

Favorite Front-end/UI developer interview questions?

Help me compile your favorite interview questions.

Guiala Jean Roger profile image
I'm a software engineer, passionnate about geographical information System. Fullstack dev, in love with javascript