iOSDev UK: Using TDD to write an iOS App

Graham Lee, professional in-betweener, @iamleeg

Or, “What is TDD and why should you use it?”

• discovering bugs is not the point of testing at all
  • instead, you are proving that there aren’t bugs
• once we’ve fixed bugs, we don’t want to see them ever again
  • tests can ensure that regressions don’t come back
• TDD allows us to prevent bugs from ever happening!
  • you won’t prove that the app works how the customer expects, but you will at least prove that it works how you expect it to work…
• TDD imposes black-box thinking for the developer
  • makes you think about how the code should be designed and scoped
• accurate planning: we know how much we’ve done
  • and we can be honest how much we have done
• TDD does not:
  • ensure that the developer understood the requirements!
  • ensure that the requirements remain static
  • ensure that pieces work together (unless you add integration tests)
• tests should be short and have descriptive, English names
  • e.g. testDatesOnTheSameDayAreConsideredSame
  • general pattern
• tests should be fast — well under a hundredth of a second each, so a second or so for all of them
  • avoid integration tests in unit testing since they take too long
  • don’t interrupt your concentration by waiting for tests
• as a result, your classes will be smaller and have obvious effects
  • any side-effects are few and easy to predict
  • if your test fixture gets big, then that’s a sign that you need to refactor (possibly including the tests!)
• TDD encourages “tell, don’t ask” configuration
  • inversion of control
  • pass in helper data rather than discover it internally
• avoiding testing everything at once:
  • use fake objects (with same interfaces) to provide simulated interactions
  • use mock objects to record and verify interactions
• Objective-C mock frameworks:
  • OCMock
  • Mocky
• Code coverage is useful for adding tests to an existing app
  • Not so useful for building new code
  • If you’re not covering code with TDD, then you’re kind of cheating yourself

Q&A

• @pilky knows about using the accessibility framework to write automated UI tests using javascript
• can use XCodeBuild to run unit tests from command line
• use GHUnit instead of built-in OCUnit to output JUnit XML reports
• iOS Enterprise Development — O’Reilly book by James Turner
  • includes lots of useful
• squish automated GUI testing?
• test code linking…
  • app should be plugin host, providing linked libraries
  • but it doesn’t work — have to link yourself from test code

Taking a day a week for yourself

More and more people I speak to are coming up with the same idea — that working one day a week for yourself gives you a better balance and loads more creativity and fulfilment. I ran a session at BarCampLondon6 on exactly this topic and it's good to hear more people starting to make similar changes to their lifestyle.

Here's Matt Webb's take:

Here’s my challenge. Right now, put aside 100 hours over this summer. Do it right now, in your head. Put that time aside. 100 hours. 8 hours a week for the next 12 weeks. One hour a day, or one working day a week. It’s one summer out of your entire life, it’s nothing. Okay, you’ve got that 100 hours?

Now for the next two days, go to talks and start conversations with people you don’t know, and choose what to spend your 100 hours on.

I guarantee that everyone in this room can produce something or has some special skill, and maybe they’re not even aware of it.

Ask them what theirs is, find out, because you’ll get ideas about what to learn yourself, and decide what to spend your 100 hours on. Do that for me.

Because when you contribute, when you participatein culture, when you’re no longer solving problems, but inventing culture itself, that is when life starts getting interesting.

I moved from taking one day off every other week to one day off every week at the beginning of June and even that has made a big difference. My personal project has been learning to build apps for the iPhone -- starting with the Stanford iPhone Application Programming course and Aaron Hillegass's Cocoa Programming for Mac OS X.

Through evenings and snatched half hours on the train, I've got through most of the course and am starting to explore other areas, such as adding hamcrest and OCMock to the built-in OCUnit iPhone unit tests. I still plan to build and release my own apps as I get more of an understanding of what's possible.

So Matt, I've taken up your challenge before you even issued it and I look forward to others doing the same!