Wednesday 7 September 2011

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:
  • 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


  • @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

No comments: