TDD and Rails Development on the iPhone
I’m filling this document in as I make discoveries, so it will keep changing. I will tweet when I do.
TDD on the iPhone
What you get out of the box on the iPhone is SenTest. There’s a lot of stuff on the web in google code that I think has been overtaken by later versions of XCode. It’s adequate, but a bit nasty to use.
- Hamcrest matchers
- Debugging tests
- Just use what you’ve got
Hamcrest
Hamcrest isn’t a testing framework but matchers that you can use with your framework. I love the syntax but just couldn’t get it to work with the latest version of XCode. There’s some kind of problem with call backs that I didn’t have time to fix. The maintainer has done an excellent job, but it covers Java/C++/… lots of languages and I suspect he can’t keep up. This probably cost me a week, because I loved the syntax so much. Ah well, so much for shiny.
Debugging tests
You set up some tests following the instructions here – what happens then is that when you choose your test target, it will run a little shell script and see if the tests succeed or fail. This works when you know what you are doing. However, if you’re a total noob and write code like this:
- (NSString *) apiUrl:(NSString *)method
{
NSArray *urlComponents = [baseUrl componentsSeparatedByString:@"//"];
NSString * baseUrlWithAuth = [NSString stringWithFormat:@"%@//%@:%@@%@/%@", urlComponents[0], username, password, urlComponents[1], method];
return baseUrlWithAuth ;
}
i.e. you assume that the NSArray will act like an array, instead of having to call the lovely objectAtIndex method. You will get a segment fault. All the output will tell you is that it failed.
So, what to do? Fire up the debugger and have a good look at things and realise you’re assuming that you can use brackets to dereference an array when it’s actually an object with array-like methods.
But, here’s the rub. If you turn debug on it will run your tests and crash, every time. There is no executable to run that you can debug.
Never fear, dear reader, you need to follow the instructions here – in essence there is an executable wrapper that Apple provide that you can use that will run the tests. You will need to do some experimenting. Also note that you need the correct version of the wrapper for your iPhone SDK, which isn’t the default one in that blog post, so you will need to do some hunting around.
This all works fine for straight classes, of course. The next thing is to look at how to test the GUI. I haven’t even started on that one yet, but there is an iTunes tutorial that you can find if you are a registered developer. I’ve only ever been able to reach this part of iTunes from an email I was sent after the last Developer Conference, so I can’t post a link here.
Libraries Gotcha
Make sure that your project’s pch file is included in the build of your test objects by setting the Prefix Header for the tests target to be the same as the one for your main target, or stuff will start moaning about missing headers when you switch to the tests build and not when you do your normal build. Also turn on the precompile flag, for completeness.
Distinguishing between development and live
URL’s etc. etc. try here – just add in the #define for your environments as required. It’s a useful post anyway.
Testing the GUI
More to come.