With the popularity of Objective-C it has brought over a lot of programmers with experience in other platforms, especially web developers (like me!).  Lately there has been a rise of many testing frameworks written by the same group of folks who test using other methodologies then what was previously available in Objective-C. This is great for the language and community as iOS development is still a little bit of the wild west. It’s also really neat to see an old language get shaken up a bit. I want to point out a few things that easily get overlooked when seeing all of these new testing frameworks.

There is always a learning curve.

A popular excuse for not having tests is its too difficult to setup and get working or you didn’t have the time. Getting tests setup quickly into your project is probably the biggest hump to get over if you’re not used to doing it. Unless you’re using Cocoapods, getting the new testing frameworks to compile could be quite a task. Xcode makes it quick to include unit tests in every new project. It even generates a template for the first test. In addition, you’re learning the new syntax and API of the new testing framework. With unit testing, unless you get to heavy mocking, you have less to wrap your head around because you’re testing the code you’ve already written.

You could be adding risk to your project.

I’ve been burned by 3rd party test frameworks. When iOS4 was released I had 300 functional tests become worthless when upgrading from the iOS3 SDK. Since a lot of testing frameworks use internal libraries and selectors of UIKit, it’s not uncommon for things to break when Apple releases an update. This is a good example of it still happening in iOS6. You’re at the peril of the 3rd party or the community to release the fixes or you’ll have to spend the time and fix it yourself. DIY can be a pretty crappy option when you’re trying to iterate quickly and ship.

You also run the risk of EOL or lack of interest from the community since something “better” came along. Don’t be nieve and believe this could never happen if the framework was open source.

Unit tests still provide the most value.

If you take a look at any of the software testing pyramids, unit testing should be the largest chunk of your tests. They are the first line of defense. I’ve talked with some “new school” Objective-C programmers and they say that OCUnit is kind of “meh” and they’ve just moved on to behavior tests without having any unit tests of any kind. This is also risky because behavior tests may not be able to find the same bugs as unit tests would. Unit tests shouldn’t be ignored like this as it’s the foundation of having bug free software.

So the next time you’re looking a newly released testing framework or you’re looking to add another layer of tests in your Objective-C project – don’t forget about the unit tests.