The results of my reader survey are in. The #1 request? Case studies of unit testing, with more complex examples. And that got me thinking about the next major direction to take this blog.
When I was first learning test-driven development (TDD), I didn’t really have any examples to look at. All I had were descriptions of TDD. I stubbornly believed that these descriptions showed a more effective way of programming, so I fought my way there through the School of Hard Knocks.
But you shouldn’t have to do the same.
Over 250 of you responded to the reader survey — thank you so much! The data I gathered is very helpful. I learned that most Quality Coding readers face two frustrations with unit testing: “I don’t know how,” and “There’s not enough time.” I think these are actually related, because not knowing how to do something certainly increases the time it takes. And the #1 request from the survey was for “more complex examples.” You want examples that go deeper than just incrementing & decrementing a counter. It’s kind of like I showed you how rack-and-pinion steering works, then said, “Now, go build a car.” That’s a big leap.
So, let’s build a car! …Or rather, an app. In the coming months, I want to work through a complete case study of how I would build an app, with you looking on. I want to show you that by applying certain practices, every iOS developer can create code that is bright, robust and testable.
Benefits of a case study
- Depth: As we work through various parts of iOS technology, we’ll touch upon many details.
- Breadth: We’ll address a number of topics other than TDD. These include unit testing, design, tools, and language issues.
- You’ll get to see when I use TDD, and when I don’t.
- Design Issues: Bright code doesn’t happen by slapping tests onto code. It raises many interesting design questions—from choosing good names, to what architecture is for.
I do want to add some disclaimers:
- It’ll take time. I don’t want to rush through this, because there will be many details I want to discuss.
- The design won’t be perfect. But that’s okay! We’ll change things as we go. Part of this whole example isn’t just the “finished” code, but the process of getting there.
- I’ll make outright errors. There are parts of iOS I’m not familiar with. I’m counting on you to help steer me straight!
Let’s do this
In his book Test-Driven iOS Development, Graham Lee spends most of his time on a single case study, a Stack Overflow browser. I want to do something similar. You’ll get to see practical approaches that you can put to work. I think it will be a lot of fun.
So: What kind of app shall we build? Leave a comment below with your ideas & suggestions!
Update: Everyone wants the app to network to some API. But which one? Be as specific as you can. :)