PragPub 2010-07: Issue #13 by The Pragmatic Bookshelf

Author:The Pragmatic Bookshelf
Language: eng
Format: epub, mobi
Tags: PragPub—Monthly Magazine
Publisher: The Pragmatic Bookshelf, LLC
Published: 2010-07-01T04:00:00+00:00

We’ll replace that test and start by writing the test that seems simplest to me—incrementing the score for player one. Let’s call scorePlayerOnePoint once, and verify that the new score is 1.

-(void) testScorePlayerOnePointUpdatesPlayerOneTextOkay

{

PingPongScorerViewController *controller =

[[[PingPongScorerViewController alloc] init] autorelease];

controller.playerOneScore = [[[UIButton alloc] init] autorelease];

[controller scorePlayerOnePoint:nil];

STAssertEqualStrings(controller.playerOneScore.currentTitle,

@"1", nil);

}

You’ll get an error because the property playerOneScore doesn’t actually exist yet, and another because scorePlayerOnePoint doesn’t exist. Normally I would have stopped at the method call, then implemented just enough to compile, then come back and finished the test, but for the sake of brevity I’ve done this all in one step. Let’s look at the assertion STAssertEqualStrings, one of the many built into GTM. It takes the actual value for its first parameter, and the expected value for the second. In this case we are checking against the UIButton playerOneScore’s currentTitle field. That’s a read-only property on UIButtons, and I’ll show you how to change it in a second. I also pass in nil for the third argument, which is an optional string format for the error message. If you pass in nil you’ll get the default, which is usually good enough. I’ve also gone ahead and added this controller to the autorelease pool for now, since this the only place I’m using it. Looking at the scorePlayerOnePoint message you’ll see I pass in nil; that’s because all Cocoa actions take the sender as a parameter, but I don’t actually care what the sender is for my implementation. Let’s make this pass in the simplest way possible.

-(void) scorePlayerOnePoint:(id) sender

{

[playerOneScore setTitle:@"1" forState:UIControlStateNormal &

UIControlStateHighlighted & UIControlStateSelected];

}

That’s a mouthful for simple isn’t it? To set the title for a UIButton you actually set it for a state—but in this case we want to set it for all the states (normal, highlighted and selected) so we bitwise and the flags together. The simple part is the hard-coded “1”. That was pedantic of me, wasn’t it, but this is an excellent example of why I do that. I didn’t have the API for setTitle memorized and had to try it several times before I got it right. By hard-coding in a one I was able to narrow down the reasons why the test wasn’t passing to just the API call. This is also why we don’t mock out UIKit objects: we really do need to know it’s calling the real object and working correctly. Now I’m going to write another test to triangulate—what happens when the player scores twice?

-(void) testScoreTwiceUpdatesPlayerOneTextToTwo

{

PingPongScorerViewController *controller =

[[[PingPongScorerViewController alloc] init] autorelease];

controller.playerOneScore = [][[UILabel alloc] init] autorelease];

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.