Archives For TDD

There’s been a growing debate about static languages vs. dynamic languages. For me, it started with Uncle Bob’s Type Wars, but it has expanded into many circles. Writing my own reaction helped me discover that I was unfairly judging Swift based on C++.

In the midst of the debate, another interesting article popped up: Eric Elliot’s The Shocking Secret About Static Types. It points to a couple of studies. One concludes that there is a lack of evidence that static typing reduces defect density. The other more rigorous paper concludes, “There is a small but significant relationship between language class and defects.”

Check out Eric’s fascinating conclusion:

When it comes to bug reduction, I think it's fair to say: Static types are overrated. But when it comes to other features, static types are still cool, and may still be worth using. Bottom line: You want to reduce bugs? Use TDD. You want useful cod intelligence tools? Use static types.

We’ve come full circle: a discussion about static types has again brought us back to TDD. Why?  Continue Reading…

My TDD has improved since I first started in 2001. But even today, I make mistakes. The trick is to learn to recognize TDD mistakes. Then, learn to “listen” to them: what is it trying to tell me about the design?

Follow along as I recount the latest steps in Marvel Browser, the iOS TDD sample app. Can you spot the errors before I point them out? Continue Reading…

TDD doesn’t make anything happen automatically. You really need to level up on two other skills as you go: design, and unit testing. Doing so can shift TDD from being daunting to being simple.

Let’s look at how a change to unit testing empowers TDD.

Continue Reading…

xUnit Test PatternsI’ve given you 3 Reasons Why It’s Important to Refactor Tests. But what’s actually involved in refactoring tests?

The definitive book on this topic is xUnit Test Patterns: Refactoring Test Code by Gerard Meszaros. It’s a big book, full of patterns and smells. But there are 3 simple steps I take most often.

Here’s a five-minute screencast where I’m refactoring tests in my iOS TDD sample app using those 3 steps: Continue Reading…

You may have seen the 3 steps of “the TDD waltz”: Fail, Pass, Refactor. There are many ways to do it wrong! Two common mistakes are:

  • Skipping the refactoring step
  • Not skipping it, but refactoring only production code

So let me give you 3 reasons why it’s important to refactor tests.

Continue Reading…

Can you TDD networking requests? Sure! It’s just a matter of using Dependency Injection (DI).

But first, a quick recap. Remember this design?

Web request: Clean Architecture

We want a Service class. Now when I began using this style, I made a mistake: I created a single Service class to house an entire API. This violates the Single Responsibility Principle.

The Marvel Browser may end up supporting only one API call. But I’m afraid naming it MarvelService would lead people down the wrong road. We are fetching comic book characters. So let’s use a narrower name: FetchCharactersMarvelService.

Remember: Smaller, focused classes are easier to manage than larger, godlike ones.

Let’s TDD it! Continue Reading…

iPhreaks is a terrific podcast done as a panel discussion. The panel often brings strong experience from other platforms. (In fact, iPhreaks is the iOS cousin to the Ruby Rogues panel.) They already discussed TDD in episode 95. Following up on that, I’m honored that they invited me as their guest to talk more about TDD and Testing in episode 116.

iphreaks Continue Reading…

We’ve TDD’d a class that should handle authentication to the Marvel API. It looks good in theory. But how do we know if it really works?

In addition to TDD-ing part of a system, it’s important to get feedback about the system as a whole. So before we go on to write code to request Marvel comic book characters by name, let’s make sure the authentication class works at all.

We’ll do that with an acceptance test.

Acceptance test: Snapping in a jigsaw piece Continue Reading…

If you don’t know what some code should do, you can’t TDD it. A spike solution (a throwaway experiment) gives enough information to begin the TDD process. But now we’re faced with design decisions: What methods do we want? How should they be organized? How should they be accessed?

With Test Driven Development, the surprising answer is: it doesn’t matter that much, because it’s going to change anyway.

Breaking “Analysis Paralysis” with TDD
Continue Reading…

Using a hammer to drive in a screw. I mean, it works, kind of.

But if you use a tool in a way other than its intended purpose, you’ll be missing its most important benefits.

It’s kind of like that with Test Driven Development.

Hammer driving screw

DSC_1607” by Justin Baeder, used under CC BY 2.0

Is TDD about preventing bugs? That’s more of a side effect than a direct goal.

Is it about making a test suite? Well, kind of. But… no. Not really. Continue Reading…