Paul's techie blog

Smart Tests Are Dumb Tests

Fri, 22 May 2009 06:26:04 GMT

A question I hear a lot is “don’t you find your test code is pretty much a copy of your production code?” Digging deeper we this kind of test.


def test_counts_the_correct_number_of_words
  sentence = "The quick brown fox jumps over the lazy dog."
  expected_number_of_words = sentence.scan(/\w+/).size
  analyser = SentenceAnalyser.new(sentence)
  assert_equal expected_number_of_words, analyser.word_count
end

Here’s what I’d write.


def test_counts_the_correct_number_of_words
  assert_equal 9, 
    SentenceAnalyser.new("The quick brown fox jumps over the lazy dog.").word_count
end

The more work we make our tests do, the more likely we are to introduce mistakes in the test code; this can be especially dangerous if we use the same algorithm as in the production code as we can make the same mistake in both places. And that’s apart from the second test being shorter and easier to understand.

So remember, kids, keep your tests dumb to keep them smart.

Technical Debt or When Metaphors Attack

Sun, 05 Apr 2009 19:00:38 GMT

Technical Debt is a powerful metaphor: it describes code-quality shortcomings in financial terms; until the debt is paid off we pay interest, meaning that it takes longer to implement new features. It’s a useful metaphor, but has limits. A few weeks ago I was annoyed when a whole room of Agile consultants took seriously the idea of “borrowing on code-quality” to get a start-up off the ground, and then repaying the debt later (presumably by hiring consultants). All my experience tells me that this is a disastrous strategy. Such debt becomes incredibly expensive to pay off – expensive in real cash.

Ward Cunningham coined the Technical Debt metaphor. He describes (on video) producing code without a complete understanding of the problem, as accumulating technical debt. By writing the code early we increase our understanding of the system: as long as the debt is repaid, this is prudent borrowing. It’s quite like a business borrowing to invest in capital equipment and using the increase in revenue to pay off the debt.

Metaphors are natural and useful thinking-tools. A good metaphor, though, can be dangerously seductive. We can be tempted to use it beyond its applicability. A metaphorical vehicle cannot fully describe its topic: they need to differ for it to be a metaphor rather than a description.

Recently Brian Marick suggested that metaphorical reasoning could be improved by listing ways in which the metaphor differs from its topic. Financial debt is easily quantifiable; technical debt is not. Borrowing on code quality to get your product out quickly is more like begging favours from the Mafia than taking out a business loan. The repayment terms are unknown, except that they will be entangling, larger, and more horrific than you can imagine.

New blog location

Thu, 12 Mar 2009 13:45:05 GMT

Because I can, I’ve decided to move my blog to here.

I’m hoping that it will be mostly seamless, with the Feedburner RSS feed and redirects taking away the pain. If it isn’t, sorry.

iPhone TDD using Google Toolbox and iphone_testify

Wed, 22 Apr 2009 10:27:53 GMT

Previously, we’d decided to switch from using Rbiphonetest to using Google toolbox for Mac code. It’s about time we got started.

To begin with we’ll just set up an iPhone project for testing. This will include automatically running all the tests every time – just like autotest.

Setting up the files

Of course you’ll need to be running OS X 10.5 (Leopard) and the latest iPhone SDK.

Fire up XCode and create an iPhone OS project. (For the purposes of this example it doesn’t matter what type; a Utility app is as good as any). I’ve written a Ruby Gem to help getting all the files in place, so we may as well use those. From the terminal go to your new application directory.

First we’ll install the gem. If you haven’t already you will need to to add github as a gem source. (If you can’t remember just enter gem source and see if github is listed).


sudo gem update --system
gem source -a http://gems.github.com

Either way, install the gem.


sudo gem install paulanthonywilson-iphone_testify

Then run the iphone_testify command.


iphone_testify

This adds the google unit testing code to the google_testing directory, creates a directory for the UnitTests. There’s also a Rakefile_ and an autoiphonetest.rb, and we’ll get round to those later.

Setting up XCode

There’s a few things you need to do in XCode. The gem doesn’t do this yet, but I’m working on it.

Create a new Target called Unit Test. Right click on Targets in the left pane. Choose an “iPhone OS” Application target and call it “Unit Test”.

Right click on the Unit Test target and choose “Add—> Existing Files”. Select all the files in the google_testing directory (or at least all the .h and .m files).

(If you’re feeling tidy, which I hope you are, you probably want to add these to a “google_testing” group as well.)

Right click on the Unit Test target again, to add a “new run script build phase”.

Set the script to be google_testing/RunIPhoneUnitTest.sh.

Add a group in which to keep your unit tests. Right click on the group and set the path to be UnitTests, so that the test classes will go where we expect on the file system.

That’s all a bit of faff. I am hoping to automate the xcode part: you can stay tuned by watching iphone_testify on Github.

Write a test

Let’s write a dummy test, just to get us started. Right click on your UnitTests group and add a new file (iPhone OS Cocoa Touch Classes – NSObject subclass). Let’s call it BlahTest.m. Add it only to the Unit Test target. Uncheck “Also create BlahTest.h”: you don’t need a header.

Edit the BlahTest.m to extend SenTestCase:-


#import "../google_testing/GTMSenTestCase.h" 

@interface BlahTest : SenTestCase
@end

@implementation BlahTest

@end

Note that we’ve included the interface definition in the implementation file: there’s nothing to stop you using a separate header file, but there’s not a lot of point. Let’s add a failing test.


@implementation BlahTest

-(void) testSomething{
    NSString *actual = @"hello matey";
    STAssertEqualStrings(@"hi mate", actual, nil);
}

@end

Run through XCode

The tests are ‘run’ as part of the build and failures are reported as build failures. In XCode set the target to “Unit Test” and build.

Run through Rake and autoiphonetest.rb

Running iphone_testify also provides you with a Rakefile for building/running the test target. From the command line in your project directory just run


rake

Even better, run


./autoiphonetest.rb

This will build/run the unit tests evertime a change is detected in the Classes or UnitTests directory. The automatic running of unit tests does wonders for flow.

The rake and autoiphonetest.rb builds will inform you of the state of the tests using Growl: to take advantage of this you will need to have Growl and growlnotify installed. In order to work around a bug in growlnotify, you need to enable “Listen for incoming network connections” in the Network pane of the Growl System Preferences.

Now we’re set up running with autoiphonetest.rb, let’s fix our test and see our pass notification; I’ll leave the test fixing as an exercise for the reader.

That’s it for now. In our next instalment we’ll look at building up or Twitter application using Objective-C unit tests.

Update: Corrected a couple of bugs:

The target must be called Unit Test (not Unit Tests) to work with my gem
I ought to have used STAssertEqualStrings for comparing strings (not STAssertEquals).

Escaping Post Parameters in Cocoa/Cocoa-touch (iPhone)

Wed, 11 Mar 2009 23:32:01 GMT

So it turns out that you need to URL encode your Post parameters if you’re doing a HTTP Post from your Objective-C. Who knew? Well probably everyone who has a passing knowledge of rfc3896. I guess I’m just used to browsers and frameworks doing the work for me.

You’d think that the stringByAddingPercentEscapesUsingEncoding method on NSString would be just the ticket. Nope. The two characters you most need to escape, ampersand and plus (&+), are not escaped. What to do? Well you could copy this code I’ve just added to Twitterlink.


-(NSString*)currentMessageUrlEncoded{
  CFStringRef encoded = CFURLCreateStringByAddingPercentEscapes(
    kCFAllocatorDefault, 
    (CFStringRef) self.currentMessage, 
    nil, 
    @"&#38;+", 
    kCFStringEncodingUTF8);  
  return [((NSString*) encoded) autorelease];
}

(Thanks to Jamie Montgomerie for confirming that I was doing the right thing with the autorelease).

Giles Bowkett Slapdown

Wed, 11 Mar 2009 23:32:01 GMT

Judging unit testing by its ability to find bugs is like judging your pet dog by his or her ability to spin webs and manufacture silk out of his or her ass.

Giles Bowkett commenting on a particularly idiotic blog post.

Stunted Framework for Java stubbing

Wed, 11 Mar 2009 23:32:01 GMT

I’ve always liked Michael Feather’s concept of stunted frameworks. I write a lot of code that could be re-used, but it is tailored to specific projects. Adding hooks, and configuration to make the stuff more generally useful and releasable as open-source just feels like too much hassle. I wouldn’t mind, so much but I don’t want to add bulk and complications to the code I’m working on. In any case, the chances of it matching everyone else’s edge cases are slim.

Look what happened to David Megginson when he wrote SAX2:

people were screaming for all kinds of esoteric stuff that about 12 people in the world care about (i.e. entity boundaries) ….. SAX ended up with all kinds of new, optional interfaces in the distribution anyway, so it’s quite nightmarish for a new user trying to figure out what matters and what doesn’t.

It recently occurred to me that Github is an excellent mechanism for distributing stunted frameworks. To that end I’ve just added (a tiny) one for writing stubs in Java, by providing partial implementations to an interface. I first wrote about it in 2005 and have since then used it on many Java projects in lieu of more sophisticated mocking libraries.

For more information go to the project at http://github.com/paulanthonywilson/dummy-proxy/tree/master

My command line prompt with Git

Wed, 11 Mar 2009 23:32:01 GMT

All the cool kids these days like to have the current Git branch as their command-line prompt. Call me old fashioned, but I like to know my current directory as well. As showing the full path can get ridiculous, I just want the directory name.

This is what I ended up with in my .profile:


export PS1=\
'$(echo $PWD| sed s/.*\\\///) \
$(git branch &>/dev/null; if [ $? -eq 0 ];\
 then echo "(\[\033[00m\]$(git branch | grep ^*|sed s/\*\ //)) ";\
 fi)\$\[\033[00m\] '

(The Git part was copied from the Internet somewhere – I forget where.).

This is what it looks like:

Giving up on Rbiphonetest

Wed, 11 Mar 2009 23:32:01 GMT

I’ve enjoyed using and writing about Dr Nic’s Rbiphonetest. It’s been cool being able to at least do the testing point of iPhone development in Ruby, which is far more succinct, DRY, and expressive than Objective-C. It’s also handy to be able to take advantage of Ruby’s mature testing frameworks.

I’ve even been able to test the iPhone’s UI widget interactions, which Rbiphonetest is not supposed to do: it needed a hack, but it was a clever hack – and that’s the problem. Rbiphontest is a clever experiment, but it seems to have run its course. Anywhere off the standard path (UI, Catagories, creating one model in another) is strewn with traps and difficulties. Even Dr Nic seems to be discouraging its use.

So expect more blog entries about Rbiphonetest. What I will be writing are some tutorials on doing iPhone TDD using the Google toolbox for Mac. I’ve got something like autotest running with it already. Stay tuned.

Twitterlink available on Apple's Appstore

Wed, 11 Mar 2009 23:32:01 GMT

Talking of Twitter clients, my first iPhone application – Twitterlink – is now available on the AppStore. It is a simple beast with one purpose: it enables posting shortened URLs from iPhone’s Safari web-browser to Twitter.

You can download Twitterlink from the app store here (app store link), or read a little more about it here.

It’s free for now. I will be putting the price up to (gasp) £0.56 ($0.99) soon.