Quality Coding

Category Archives for TDD

Emoji: Graduation Cap

Advanced TDD Workshop for iOS Developers — On Sale Now


Have you done a few TDD exercises, but wonder how to bring it to your actual production code? Are you doing TDD in production code, but only for the simplest business rules? Did you TDD something only to feel it went poorly, and left your code worse off? Then it sounds like you’re ready for an Advanced TDD class.

Continue reading

Emoji: Fearful Face

Don’t Give Up on TDD Before Reaching Your Breakthrough


Dan Abramov recently tweeted:

That’s the beginning of a thread, so there’s more to it. But it gives me a chance to say to Dan, and the many folks who’ve shared this: You can still grow in Test-Driven Development. (Heck, I’m still growing.)

But instead of short tweets commenting on other short tweets, I thought I’d reply here. There’s room to discuss the gray areas.

Continue reading

The 3 Laws of TDD: Focus on One Thing at a Time


When I was first learning TDD, I’d try to get to the First Step (a failing test) by writing a fully-formed test. But it often took a lot fiddling to get that test to run and fail. Sometimes this was because the production code took several steps to set up. Sometimes it was because the test code wasn’t right.

One of the tricky parts of TDD is that we’re creating two streams of code in parallel: the test code, and the production code. Two things changing at the same time… that’s a hard thing to keep in your head!

Continue reading

Emoji: No Good Gesture

Incorrect TDD: What Can We Learn From It?


A paper published in 2013 about Test-Driven Development included the following diagram. Unfortunately, it gets some things wrong:

A tweet from Nat Pryce sparked discussion:

First, let me say I’m happy to see more studies on TDD. The thrust of this particular study is that TDD can be soft on negative tests. That is, maybe the code works for good data, but it’ll break on bad data.

TDD is a development discipline, so I’m all for learning more from traditional testing disciplines. I certainly don’t want to discourage folks from doing studies and writing papers.

But. Let’s first make sure we’re doing proper TDD, shall we? Otherwise any studies, especially studies about efficacy, may be flawed.

Continue reading

JSON Parsing: One of the Easiest Places for TDD Beginners


How can we use Test-Driven Development for JSON parsing? Most developers are concerned with ways to implement the production code. There are various approaches, various libraries… But what about the unit test side of things?

If we write effective unit tests, the design can appear incrementally. And with a strong suite of tests, you’re free to change the implementation — even radically. When the results are guaranteed by tests, whatever approach you take or library you use becomes an implementation detail!

Last time, we looked at design principles, such as sticking to the Single Responsibility Principle and returning a Response Model. This time, let’s look at:

  • Test principles
  • A TDD demo in Objective-C

Continue reading

Rubik's Cube

TDD Sample App: The Complete Collection …So Far


When I began my TDD Sample App, my hope was that it would help us explore a number of topics around TDD and Tidy Code.

On one hand, the app itself has barely progressed. However, the blog posts cover a surprising variety of topics.

By User:Booyabazooka, User:Meph666 modified by User:Niabot (Image:Rubik’s cube v2.svg) [GFDL or CC-BY-SA-3.0], via Wikimedia Commons

Continue reading

Emoji: Horizontal Traffic Light

Static Analysis: Will It Free You from the Need for TDD?


There’s been a growing debate about static languages vs. dynamic languages. For me, 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 study concludes that there is a lack of evidence that static typing reduces defect density. The other study 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

Emoji: Man Facepalming

How a TDD Mistake Revealed an Error in My Design


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?

[This post is part of the series TDD Sample App: The Complete Collection …So Far]

Continue reading

Can TDD Be Simple? With Preparation, Yes


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

Simpsons bully Nelson Muntz mocking,

Type Safety vs. 100% Coverage: Who’s Right?


“You don’t need static type checking if you have 100% unit test coverage.”

This is one of the closing statements from a post called Type Wars. Various people jumped all over this, with much LOL.

Who’s right? Is the post right? Are the detractors right?

Applying my faith to life, I find that “right and wrong” isn’t a helpful filter.

I want to start by trying to see the points of view of the detractors. But then I want to expand on the controversial statement, from my point of view. Finally, what do I think this means for Swift?

Continue reading

Web request: Clean Architecture

TDD Networking with DI: Is It Really That Easy?


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

But first, a quick recap. Remember this design?

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

Emoji: Studio Microphone

My Interview about TDD on the iPhreaks Podcast


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.

Continue reading

Emoji: Puzzle Piece

But Does It Work? Boost Confidence with Acceptance Tests


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.

If I’d been a little more on my game, we could have written the failing acceptance test before beginning our TDD. The acceptance test would drive the TDD from the outside-in. Once the acceptance test passed, we’d know the code was functional. That top-down approach is called Acceptance Test-Driven Development, or ATDD.

But I ended up doing a bottom-up approach. So let’s add an acceptance test now.

[This post is part of the series TDD Sample App: The Complete Collection …So Far]

Continue reading

Icon: Person faced with choices

7 TDD Techniques from a Case Study


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.

When I began playing electric bass for high school jazz band, I was often uncertain of the right notes to play. Rather than play a wrong note, I opted to stay silent. The band director finally got frustrated and yelled at me: “I don’t care what you play… just play something!” I learned that the bassist’s role is to establish a good rhythm. A wrong note on the beat is better than no note, because it keeps the rhythm moving.

People beginning Test-Driven Development sometimes freeze up, not wanting to play a “wrong note.” But the purpose of TDD — to get rapid feedback on your code — won’t happen if you stare and think too long. The way to break “analysis paralysis” is to move ahead with a failing test, even if you’re not certain it’s the right one.

In this post, look over my shoulder as I try to apply this TDD mindset to write code that authorizes requests to the Marvel Comics API. Let’s see if any TDD techniques emerge.

[This post is part of the series TDD Sample App: The Complete Collection …So Far]

Continue reading