If you have ever written a unit test, chance has it that you used either black or white box testing techniques to determine what that unit test was testing. In this post I want to explore both these techniques and look at when we should be using them. Black-box techniques Black-box testing i

I find it surprisingly hard to get new developers to really engage with unit testing but then when I think back to when I had just graduated and what I thought about unit testing: I'm here to write code, not to test! I shouldn't be surprised. Unit testing works slightly counter intuiti

"appledoc is command line tool that helps Objective-C developers generate Apple-like source code documentation from specially formatted source code comments. It's designed to take as readable source code comments as possible for the input and use comments as well as surrounding source code

iOS hasn't always been the most unit-test friendly environment, but since Xcode 4 this has changed - a lot of the setup has now been automated away for us. These improvements make adding unit tests to your application easier than ever. However, the question remains: What should be tested?

Bugs only exist in software because we as developers introduce them. We don't mean to introduce them however there is no denying that they exist and that we've all come across them at some point in the software that we use. Thankfully there are a range of testing techniques that we can emp

I've been dealing recently a lot with OCMock [http://ocmock.org/] and while is great there is some draw backs for it. The major one that I had was when I was writing integration tests for a legacy library that we have. I needed to override a method of an object that was inside a method that I wa

The other day I was developing a dictionary view controller that consisted of a UITableView and an NSArray (approx. 4000 elements) holding the data to be shown. As the elements were of varying lengths I had implemented the delegate method: - (CGFloat)tableView:(UITableView *)tableViewheightForRowA

If you have ever seen the following pattern and wondered why: NSObject *newObject = [[object retain] autorelease]; return newObject; Well wonder no more! The reason behind this retain/autorelease pattern is to ensure that the "object" will not be destroyed until the caller's aut

The other day I had to resubmit my CSR file to the iOS Provisioning Portal as I was moving mac (and no longer had access to my old mac to move credentials across). Having did this before (on this mac in fact) I thought it would be a straight forward task: 1. Open Keychain Access 2. Select "R

When writing a class or method, the way that I view other classes that want to use my class is as my enemies (even if I’m writing the other classes!). That might should dramatic but I take the approach that what ever is going to use my class might not properly understand the class and feed it junk.

I sometimes see code where the delegate has a type of NSObject rather than id: id<CustomDelegate> delegate; NSObject<CustomDelegate> *delegate; and when asked "why" I'm always told the same answer: "So that when using the delegate I can use the performSelector metho

I ran across the scenario where I wanted to disable the paste functionality on some textfield in my application. I've did this many times before and quickly added the following method to my viewcontroller: -(BOOL)canPerformAction:(SEL)action withSender:(id)sender { if ([UIMenuController s

Application requirements evolve, which require us to refactor existing features. For the most part, Xcode's built-in refactoring tools work well; however, an area where the refactoring tools can't help is with stringy APIs. Core Data seems to be full of stringy method parameters - in this ar

A common mistake I see over and over again in code is the accidental double retain. This happens when an object is set to a property that has the attribute retain which results in a memory leak. Let's look at an example of this happening: @property (retain) UIView *doubleRetainedView; @pro