Good old fellow speaker Jim Holmes had a great addition to my recent post on TDD tips for scrum teams:

Get a coach to embed with the team–someone who’s got practical, hands-on expertise in implementing TDD in legacy systems.

Trying to get TDD rolling on existing codebases is hard, hard, hard. Having a guide to help the team figure out how to succeed at TDD is critical.

I couldn’t agree more.

I was once asked to work with a team to help them improve their TDD practice. Except that they weren’t practicing TDD yet.

The team had taken a TDD class and started to write as many tests as they could. They said: “our test files are very cluttered, very brittle“. Yes they were.

As the team describes what they are experiencing, it is clear that the tests are written after the feature implementation. Further inspection of the test files confirms that, with signs of copy-and-paste throughout and across several files.

Had the team stayed on that path, they’d quickly abandon tests altogether, as it was getting too hard to maintain those tests and write new ones.

By getting a few sprints of coaching, they learned to:

• refactor the existing tests
• identify flaws in the software’s current design and implementation
• start developing the mindset of test-driven design

Start with a great training course, commit to applying what you’ve learned, and then follow it up with great coaching.

🚨 Spoiler alert: the evidences you seek aren’t likely to be found here!

There are a number of studies available on the web with numbers, charts, etc. This post does NOT include any of that.

For the readers who enjoy geeking out on studies and researches, here are some great books that include some of that:

• Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations

• Specification by Example: How Successful Teams Deliver the Right Software

What follows are some of my current thoughts on the topic at hand.

Weeks ago I shared some thoughts on this question I’ve heard many times over the years: Is TDD something you do sometimes or all the time? It generated a great conversation with an old fox who has been stalking me for several years. 😉

It started like this:

I’ve never seen good evidence that TDD is better. Oh sure, there are opinions, but not concrete evidence.

That’s a common comment, so I wanted to explore it more.

As a guitar player, I’m often asked questions like “who do you think is better: Tony Iommy or James Hetfield? Yngwie J. Malmsteen or Eddie Van Halen?”

At one point in my life, I’d answer Iommy. At a later point, Hetfield. Then, at another point, Malmsteen. And depending on the day, Van Halen.

It’s all contextual. I’ve listened to a lot of music by those four guys since the mid 80’s. The circumstance, the people who were with me, my personal experiences, all of that influenced who I thought was better at one time or another.

But better at what?!

Record sales?
Influence over new bands and/or guitarists?
Number of hit songs?
Number of memorable riffs and/or guitar solos?
Career longevity?
Guitar playing technique? Innovation?
Caring for their fans?

As the old fox said, “oh sure, there are opinions…”

Over the years, I couldn’t agree with my own opinion, let alone the opinion of others. So who is better?

The fox says “…but not concrete evidence.”

Wait; what kind of evidence are we looking for? I think we’d only know that if we could answer the “better at what?” question. In the case of guitarists, if we’re considering “better at selling records”, that’s something measurable.

But who’s better: a best selling or the most influential guitarist? The latter? But most influential at what?

At some point, I gave up on answering those questions. I’ve let it go. Depending on a number of factors based on a single moment of time, I will deliberately choose one guitarist over the other.

But I digress…

So, is TDD is better?

Better at what? Better than what?

Better at decreasing bugs?
Better at increasing code quality?
Better at bringing clarity to our thoughts before we decide how we want to implement something?

Or…

Better than not practice TDD?
(I can’t come up with any other options here…)

If we manage to add more context to the question, then we can look at the next one, “is there any evidence?”, and define what kind of evidence we’re looking for, and finally look at how we could possibly measure it.

Say the question is, “is TDD better at delivering software faster than not practicing TDD?“

If we’re looking at it only in the context of a very short period, we may find it that it is not.

If we’re looking at a longer period of time, I’d bet it is better.

But we should figure out what we’re measuring besides the time spent writing tests. For example:

• time spent reading code until we feel confident to change it
• time spent on a debugger troubleshooting issues

The old fox is wise; one needs to try something before reaching any conclusions:

“I’ve tried it. I can’t say I saw an improvement in the code or fewer bugs. There’s no way to accurately measure that.”

How do we see improvement in code?

There are code metrics we can use, such as cyclomatic complexity (CC), but can one see improvement in code if CC decreases? If developers working on the code can’t yet appreciate low CC, they don’t see it as an improvement.

Occasional music listeners may not appreciate improvements in remastered albums. Many times we need to be trained so we can start seeing (perceiving?) things as improvements. As someone who dabbles at playing classical guitar, Julian Bream’s Masterclass videos has made me hear and see nuances I was respectively deaf and blind to before.

The fox continues:

“But when I wrote code I refactored a lot, not just the code I was writing, but the existing code around it. So that could have an effect on quality.“

That reminded me of Michael Feathers’ Working Effectively with Legacy Code, when he talks about pinch points (here’s a good short description).

But the old fox wasn’t finished:

“I think there are enough developers out there that don’t know how to do unit testing properly. If we want to turn them into TDD devs, first they need to learn how to write good unit tests. Here’s an example: At my last job, I was moved to a team that had little unit testing. They owned code that I was told “It can’t be unit tested.” I showed them it could. Once they’ve learned how to effectively unit test, only then should they be pushed to TDD. At least, that’s my opinion.“

BINGO! That resonates a ton with my own experience. Years ago I even gave a talk titled “I Cannot Write Tests for That!”: UI Edition. I’ve had several similar experiences coaching developers into the practice just like the fox described. I draw great satisfaction from helping developers through that journey, and more often than not, I don’t have to “push them to TDD”; they are the ones “pulling for it”!

Final thoughts for now…

If I am to look for “evidences that TDD is better”, I think of what works for me and those around me:

• The time spent designing potential solutions to problems is time well spent
  • and it is shorter than the back and forth of implementing features without designing them
• It’s very satisfying to be able to refactor implementation when there are good specs to back it up
• The level of willingness a development team shows to embrace changes
• It feels very pleasant and productive to collaborate with others and have conversations using well-crafted specs

Now if you excuse me, I have some TDDing to do.

Maybe.

But first, I’ll start by clarifying that developers asking that question usually mean “test doubles“, instead of “mocks”.

Some situations that might indicate code smell in tests include:

• using several test doubles to test one thing
• complex test doubles setup

Both cases aren’t only an indication of a code smell in the test; they often indicate a bigger problem: code smell in the design!

If the system under test (SUT) requires too many test doubles to satisfy its dependencies, it likely violates the Interface Segregation Principle

A client should never be forced to implement an interface that it doesn’t use, or clients shouldn’t be forced to depend on methods they do not use.

Take the example below:

public class SomeClass(Dependency1 Dependency1,   
Dependency2 Dependency2, Dependency3 Dependency3, 
Dependency4 Dependency4)
{ 
 public void SomeMethod()  
 {    
   if (dependency1.CheckThis() && 
       dependency2.CheckThat() && 
       dependency3.CheckSomethingElse() &&   
       dependency4.FinalCheck())    
   {
       // do the thing...    
   }
  }
}

To write a unit test for SomeMethod, we would need mock each one of the 4 dependencies.

By inspecting how those dependencies are used, we could identify a new abstraction that offers what SomeClass needs:

public class SomeClass(Dependency Dependency)
{  
  public void SomeMethod()  
  {   
   if (dependency.CanIDoTheThing())     
   {     
     // do the thing...    
   }  
  }
}

Now there’s only one dependency to deal with in tests, and it’s easier to learn what that dependency provides.

An example of code smell

Here’s a test I’ve run into many years ago:

According to the name of the test, it verifies that the “PUT method returns OK and PortfolioModel when service response is successful“.

When I’ve read through the test, these considerations came to mind:

• Number of stubs and mocks (mockPortfolioService, portModel, response, portfolioModel)
• Overuse of Arg.Any
• Arg.Any hiding the meaning/intent of several parameters
• Unclear what “Configure” is all about (what does it mean to return true from it?)
• What’s the difference between portModel and portfolioModel? Why are both needed?
• The file had about 40 tests that looked very similar to this one in terms of mocks and stubs; a product of copy-and-paste.

After raising the issues with the developers on the team, we identified the design issues that resulted in tests having to be written that way. The tests were rewritten to isolate and call out the issue, and a design change was proposed.

“Is it worth writing test code for application logic (as opposed to business logic)?”

• Yes.
• Not all of it.
• Not always.

Test what yields business value.
Making the development effort more efficient may yield business value.

If application logic is directly related to business value, it needs automated tests.

If lack of tests for application logic delays development efforts (including manual testing), then it’s worth writing tests.

An example…

As a developer, I like being able to take an API contract designed by the team (the URI to the endpoint and the shape of the input and output) and write a quick test for it that we can use to make sure the endpoint works as expected.

This is what such tests look like:

On the left, we see the test. On the right, we see the expected payload and response.

This integration test verifies that:

• The route exists
• The json payload can be handled
• The response gets serialized into the expected json

But not only that, it also verifies any middleware that exists between the route and the controller, so things like authorization, model binders, dependency registrations, etc.

We either find a test harness, or build one, to make such tests easy to write, so there’s no reason not to.

The example above:

• Does not need any special tool
• Is written in plain C# and xUnit.net

In summary, when deciding what we should write tests for, “application logic” also comes into consideration.

That’s another common question: Is TDD something you do sometimes or all the time?

The short answer is neither. Or, “it depends”.

But let’s explore the long answer…

When I started learning TDD, yes, I’d do it all the time.

“But have you always worked on projects where you could do TDD all the time?!”

Most certainly I have NOT!

There are times when I can’t do TDD on a project.
That doesn’t prevent me from still doing it on the side.
I learn and practice it on my own time.

TDD became something I do most of the time, but never all the time.

So when do I NOT do TDD?

There are situations when I specifically choose not to do TDD. Here are some that come to mind…

Exploring a library or framework

When trying to learn what a library or framework can do for me, and how I’m supposed to use it.

Once I identify ways I’ll use it, I often refactor those tests into Given-When-Then, documenting my understanding and assumptions, so I can later remember what parts of it I’m using.

That approach also provides a safety net when consuming updates to those packages (identifying breaking changes and such).

Exploring approaches

Sometimes I need to implement features that currently lack clarity, so I want to gather feedback from stakeholders as soon as possible. I may try a few different approaches and won’t do TDD.

I will, however, use BDD (Behavior Driven Development) to describe, to the best of my ability, the feature we’re building.

Solving small problems

If a problem is too small and yields very little value, I may skip TDD.

Pitfalls of TDD

Remember Design Patternitis? That’s something most developers face when we learn Design Patterns; we start trying to apply them everywhere! As mentioned earlier, TDD is not something to be done always, everywhere, every time.

Another situation I see often is “copy-and-paste inheritance”; tests are initially written carefully following TDD, but then every new test comes from copy-and-paste, without any effort going into refactoring the test code. This is a pitfall that happens in most automated tests, and tests written following TDD can also suffer from it.

But BDD…

I try to do BDD most of the time, even if it means writing the stories and scenarios on a napkin.

Many times I don’t even know how I’ll actually implement the specs/tests, but I still write those English sentences before trying to write any code. No GWT, No Code!

So what’s the different between Test-Driven Development (TDD) and Behavior-Driven Development (BDD)? I’ve written about that before, but I think that post lacks something more illustrative.

For one thing, I forgot to mention: I’m in the camp that thinks of the last D as design, instead of development. That matters.

I’ve heard developers say things like:

• “I don’t do TDD anymore, now I’m BDD all the way!”, or
• “I only do TDD, because I can’t use Cucumber, SpecFlow, or any one of those BDD tools.”

Here’s how I see it…

At some point, I learned to write unit/integration tests in this manner:

Through TDD, I learned to write such test before writing the actual code.

Then I learned about “BDD-style” tests, so I refactored tests such as the one above into the one below:

That was my transition from Arrange-Act-Assert (AAA) to Given-When-Then (GWT).

Then I learned that BDD and TDD go hand-in-hand:

No special tools, languages, test frameworks. In the example above, just plain C# and xUnit.net.

In summary:

• BDD specifying the desired outcome
• TDD specifying the desired approach to achieve the desire outcome

Is Test Driven Development (TDD) practical when working with a lot of legacy code?

Yes, it is.

There’s an opportunity to practice Test Driven Development (TDD) whenever we write new code in a legacy system. As an example, when writing a new component, service, feature, etc., which is going to be called from the legacy system.

But what if the new code is to be written right in the middle of existing legacy code?

There’s still an opportunity for TDD.

Think what the new code is supposed to do.

Maybe it’s a new if-block that checks some variables in the existing code. That if-block asks the system a question; could that question be implemented as a method, a function, or similar approach, and then called from the existing code?

Or maybe the new lines will perform some sort of task, which is an opportunity to follow TDD to design and implement the new task, and then call it from the legacy code.

What about testing the existing legacy code?

There’s a possibility that the current state of the legacy code is so poor that even changing it to call any new code is so hard that a decision is made to only change the old code, and therefore, leaving no room for TDD.

If that’s the case, there’s still value in at least trying to write characterization tests for the existing code. That’s one scenario where using code coverage can yield benefits, as opposed to the bad way many people use it.

The existing system may be massive, so it’s important to know what we should write tests for.

What do we get from that?

The experience acquired with writing tests for legacy code makes us stronger TDD practitioners; as we experience the pain of writing tests for code that wasn’t implemented and designed with testability in mind, we also apply those lessons when designing new solutions.

But what if I’m working on a greenfield project and there’s no legacy code here?

Isn’t there? Are you sure? Many developers think of legacy code as code written a long, long time ago, often in defunct languages.

Michael Feathers defined legacy code as “code without tests”.

I’ve learned to think of legacy code as “code nobody wants to deal with, with or without tests”.

Sometimes a decision is made NOT to write tests (topic for another post). We can still write the code in ways that people won’t feel compelled to run away from it, even if there are no tests yet.

Sometimes we write tests within a sprint, but we do a poor job at writing those, so tests become “code nobody wants to deal with”.

In case you haven’t already, make sure to read and apply techniques from Michael Feathers’ Working Effectively with Legacy Code.