Xcode TDD 101: The Bowling Game Kata

August 28, 2011 — 4 Comments

How do you learn Test Driven Development? I could explain the principles and practices of Xcode TDD, but the question that comes back is, “But what do I actually do in Xcode?”

That’s what the Bowling Game Kata is for. (Download PDF.)

Xcode TDD Code Kata

Highkick” by Pandiyan, used under CC BY-NC 2.0 / Added text

What’s a code kata?

“Kata” is a Japanese martial arts term for choreographed patterns of movement. Also called “forms,” both students and masters practice these detailed patterns over and over, so that the movements can come without thought.

A “code kata” applies this idea to coding. Some use the term to refer to coding puzzles (how would you code this or that) but let’s be faithful to the martial arts metaphor. A code kata is a set of moves, meant to be memorized and practiced until they can flow effortlessly. “Uncle Bob” Martin designed the Bowling Game Kata to impart the moves of test driven development. I have taken his presentation and created a version showing these moves in Objective-C with Xcode 5 or 6.

Specific moves for Xcode TDD 101

I’m not there with you to walk through my “Xcode TDD 101” presentation, so let me call out some specific parts:

  • Slide 12: You can set up your Xcode display to mimic the slide. Click the test file so it shows. Option-click the .h file so it shows on the right. Shift-option-click the .m file and double-click the “+” in the bottom right.
  • Slide 23: Select the two circled lines, then use the contextual menu to Refactor → Extract.
  • Slide 40: Rename loop variable “i” in one shot by selecting its first appearance and doing Edit All in Scope. This is available through the menus, or in a little pop-up menu that appears when you hover over a selection, as shown here:Edit All in Scope in Xcode

Going through the kata

If you’re doing this on your own, I’d recommend going through the entire kata, once. Then go back, and break it down:

  • Begin / Verify that tests run.
  • The first test.
  • The second test.
  • The third test.
  • The fourth test.
  • The fifth test.

Memorize each section in turn. For example, work on “Begin / Verify that test run” and get it down before you move on to “The first test.”

Time-frame: Leading my coworkers through the first three tests took an hour and a half. I left the last two tests as homework.


Ready? Download the Bowling Game Kata for Objective-C and start practicing Xcode TDD!

(If you subscribe to Quality Coding, you’ll receive a free set of Xcode code snippets that will give your unit testing moves even more “flow”.)

Question: How did it go? Leave a comment below.

Jon Reid

Posts Twitter Facebook Google+

I've been practicing Test Driven Development (TDD) since 2001, and applying it to Objective-C since 2005. Learn more on my About page.
Disclosure of Material Connection: Some of the links in the post above are "affiliate links." This means if you click on the link and purchase the item, I will receive an affiliate commission. Regardless, I only recommend products or services I use personally and believe will add value to my readers. I am disclosing this in accordance with the Federal Trade Commission’s 16 CFR, Part 255: "Guides Concerning the Use of Endorsements and Testimonials in Advertising."

4 responses to Xcode TDD 101: The Bowling Game Kata

  1. Hi Jon,
    I really enjoyed the kata, and I appreciate the work you’ve done to explain the mechanics of doing TDD in Xcode. Also, thanks for making the improved template available.
    On Slide 38, why do you immediately recognize the flaw in the design and refactor it then and there? At that point in the project, the design seems perfectly suitable for the tests that have been written, and a new test (like testOneStrike) would highlight the flaw and force the refactoring.

    • Robert,
      I’ll try to explain Slide 38, but need to back up. testOneSpare was introduced back on Slide 29, as a failing test. In the process of trying to think about what to code to get it to pass, we discovered deficiencies in the design. So we comment out testOneSpare in order to concentrate on refactoring — wearing one hat at a time.
      As of Slide 36, the refactoring has been proved successful. So I re-enable testOneSpare, and run it to see that it’s still a failing test.
      On Slide 38, I’m back at the point of trying to code something that’ll pass testOneSpare. This is the second try. Again, I discover a deficiency in the design. So once again, I switch hats by commenting out the test, concentrating on tweaking the design (refactoring) in a way that doesn’t break the previous tests.
      This illustrates the principle of wearing one hat a time. Either you’re coding to get a new test to pass, or you’re refactoring. But don’t do both at the same time. We’re basically walking on stilts: Lift one, or the other, but not both. :) By keeping one foot grounded, so to speak, we reduce the risk of falling over.
      Does that makes sense?

  2. Daniel Stokowski January 10, 2014 at 1:10 am

    Hello Jon.
    Thanks for great excercise. It’s awesome! I practised it yesterday and have some thoughts:
    – Apple template looks almost like yours now (XCode 5), and it’s easier to use it than run yours (I couldn’t manage it to work – tests wasn’t being run)
    – Last test was successful without any changes in code (code from previous test was enough) – is that ok or I missed something?

    If you want I can send you detailed description what went different than in yours PDF so you can update it for XCode 5.

    Have a nice lecture here in Poland. Sad that I missed opportunity to be there. :(


    • Daniel, I’m glad you found it helpful.
      – Yes, Apple’s latest template finally addresses my concern. You no longer need my template, unless you want to use the older SenTestingKit.
      – The last test is a surprise: it basically shows that there’s nothing left to do! But it’s hard to tell without a test to prove it.

      Polish hospitality is wonderful! I had a great time, and look forward to going back.

Leave a Reply


Text formatting is available via select HTML.

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> 

Have you Subscribed yet? Don't miss a post!