'TDD Is An Essential' | Martin Fowler On Test Driven Development And Self Testing Code

Martin Fowler talks to Dave Farley about TDD, whether he thinks it is essential for large organisations in software and the term that he thinks sums up his preference more accurately.

--------------------------------------------------------------------------------------

⭐ PATREON:

Join the Continuous Delivery community at access extra perks & content, join in our CD Discord discussions and support the CD YouTube channel.

-------------------------------------------------------------------------------------

👕 T-SHIRTS:

A fan of the T-shirts I wear in my videos? Grab your own, at reduced prices EXCLUSIVE TO CONTINUOUS DELIVERY FOLLOWERS! Get money off the already reasonably priced t-shirts!

🚨 DON'T FORGET TO USE THIS DISCOUNT CODE: ContinuousDelivery

-------------------------------------------------------------------------------------

🙏The Engineering Room series is SPONSORED BY EQUAL EXPERTS

[jimhumelsine]

I have a TDD story. A few years ago one of my son's friends, "John, " was taking an intro computer programming class at the local state university. I told him that I'd be happy to help him at anytime. He came to me with a programming assignment that he couldn't figure out.

The assignment was horribly described. It took me over an hour just to figure it out too. In short, it was an assignment to create an arithmetic evaluator. Given an arithmetic expressions, such as "3 + 4" it would return 7. It also had a symbolic dictionary where variables could be stored, so that it could evaluate expressions such as "a + 5" and if "a" were loaded with 7, then it would evaluate to 12. The assignment description did a poor job of separating the description of the behavior from the symbolic dictionary from the execution framework.

So I asked John when it was due. "Two days, " he responded. Then I asked him how long he had had the assignment. "Two weeks, " was his reply. I gave him a bit of a tongue lashing and then realized that I needed to do more than just provide the assignment context and send him on his way.

I still wasn't sure whether my interpretation was correct. John's development environment was Java in the Eclipse IDE, similar to what I had used at work myself. I told him to trust me and that I wanted to try something. I typed in @Test and I wrote a very simple test in his implementation file, and sure enough, it ran. Sweet.

I wrote the first test, which was basically assertEquals(4, evaluate("4")). It failed, since he had no code yet. We wrote the function and just returned 4. Then we tried with "5" which failed. And we used the Java Int Parser to make it work for both. I tried my best to explain TDD as were doing this.

We added a test for "3 + 5" and it failed. We updated the code to recognize the "+" and use recursion, which John understood. We did the same for "3 * 5". And then we created a test that used symbols, etc.

It was all moving so quickly, that I had to stop at this point for fear that I was contributing too much. I sent John home.

I saw him a few days later and asked how it went. He had gotten an "A". He got everything working except for parentheses parsing, which were bonus points.

Then he added, "That TDD thing that you showed was really great. Why aren't they teaching this to us in school?" That is an excellent question indeed!

[michaelslattery]

TDD is unfortunately misunderstood by many who do it poorly and so then think it doesn't work. Follow Bob Martin's 3 rules. Test behavior, not implementation (which partly means to usually only test the highest api; don't write a specific test for every class (i.e. middle layers)). Use an automatic continuous runner. Unit != a class; Unit == a single functionality.

[himansrivastava]

Always a pleasure to watch these legends talk! ❤

[dflor]

TDD is wonderful, but one thing I've found when pairing with junior engineers is that they struggle with coming up with effective tests because they have trouble with designing the tests themselves. Some of the questions I've gotten are: How do you test a REST API with TDD? How do you effectively mock the test dependencies? How do you make it easy to generate inputs for your tests? I think in order to become a better engineer and to be more effective at TDD, you need to become a better tester. On that note, I would love to see some content on effective testing principles.

Some ideas if you haven't already done videos on them:
- Builder patterns for building complex objects for your test inputs
- The humble object pattern Martin brought up
- Patterns for testing APIs
- What to test at which layers of the test pyramid
- Blackbox vs whitebox testing
- How do you integration test your repository layer (in-memory DBs, etc.)

[craiggabriel]

I have been doing TDD for well over 10 years now. I can’t write code without doing the tests first it just seems unnatural to me now. Recently I was just playing around with some code and still found my self doing TDD so that I could outline what I wanted the code to achieve. What I have doing is that TDD makes me think about the problem I am trying to solve. I can write out the scenarios as tests that cover the problem and then write the code to enable the solving of the problem based on those tests.

[RU-qvjl]

“It’s depressing because it’s taken so long”. That encapsulates how I feel about so much of the software industry. All the way from companies becoming more agile, TDD being used, projects/products released, people realising they are rehashing the same ideas from 20-40 years ago but they just never studied the past.

[DedicatedManagers]

Have you ever done a video on the Humble object? I’ve never heard that term before.

[rianby]

There's one quote I love to tell my colleagues... if you cannot write the test for the feature you're about to develop, then you rather don't understand the feature.

[orange-vlcybpd]

I was recently sitting on a bunch of a procedural-style code, and scratching my head how i works, and at some point i started to look for the joint points inside this code, and refactored it in a way that i could create checks for every joint point, and that helped me understanding the code (=write tests to proove your assumptions) and it shortened the feedback cycle as i was running the code up to the test checkpoint instead of running whole ci pipeline every time i changed something in the code i wasn't understanding fully.

[nickpll]

One thing I've struggled with is working out the best way to do mocks in TDD. My preferred approach is using dependency injection, but this can get complicated if you are mocking a function that is called twice and has different outputs e.g. a loadData() function. I prefer DI to stubs as stubs can quickly turn a test file into a mess. Do you have any thoughts on mocking best practises?

[raymitchell]

Thanks Dave and Martin you're two of my favorite authors I look up to... and I hear ya... I wished these practices were more widely accepted and practiced. Much of my career was before TDD was developed, and I'm on teams that don't practice TDD... but I do from time to time and it's day and night difference. What I think isn't so clear is TDD in the embedded space with small memories... something universal and as you said the "durable" ideas to carry over into these tiny environments. I've looked at several C-Unit like open source projects, but nothing has really been that "Lightbulb: Ah-HA this is it!!!" moment for me. If you read my comment and have a recommendation I'm 100% open to hearing it! Thanks again so much.

[thatoneuser]

I'd love to see a video on your thoughts on ping-pong programming as a way to combine TDD with pair programming. I feel like the switching back and forth would create an interesting sense of competition mixed with collaboration that would put you in a state of rhythm and flow, while allowing each other to discuss design decisions and allow for knowledge sharing.

[softwarearchitecturematter]

Nice comment . It is very hard to write bad code with TDD. :)

[killiangrieg]

Dave, would you consider doing a video regarding specific tooling? Such as, Jenkins, GitHub, etc...?

[IronCandyNotes]

weirdly humanity build so many things without TDD... its madness.

[mattbristo]

Don't tell my team that. They can't even unit test.

[musicarroll]

Have experimented with a TDD approach to using ChatGPT to produce code?

[tongobong]

The problem with TDD is this: 'To a man with a hammer, everything looks like a nail'. TDD is a great tool if you know when to use it and also when you should NOT use it.

[SlowAside]

Apply the lessons of BDD to TDD.

BDD is TDD done right.

[Tony-dprl]

If TDD is "essential", why are <10% of developers using it after a decade (from surveys in 2020 I believe)
Wouldn't that imply it certainly is not essential?
I mean, software is still being developed and released, and I use a lot of applications every day that work really well ... almost none of them developed with TDD
Just saying.