AppDelegate… It’s one of those classes that can typically become a dumping ground for a bunch of code that is global (even though it probably shouldn’t be, see God Object). Well, that’s an entire discussion that could merit an entire blog post itself, but for now, let’s talk about how to avoid the execution of code in the AppDelegate in tests by using a simple trick in main.m.
Like most development tasks, eventually you get pulled into different directions while attempting one particular task. This blog post is no different. I’ve taken a brief pause (well it you check the dates it’s not too brief) to cover some additional testing needs, but it’s time to get back on the BDD wagon with some more advanced testing techniques that are necessary when handling app networking.
Oh, the joys of the open source community! There was once a time when the only testing choices an iOS developer had was Kiwi and Cedar, but thanks to all those developers out there, we now have a some additional choices.
Since we’ve covered most of the meat in the previous two blog posts with CocoaPods, Cedar and Rake, we will now finish it up setting up our own continuous integration server using Travis-CI.
Last post I showed you how to install Cedar using CocoaPods to provide us with a convenient way of handling dependencies, and to get to our end goal (automated builds). Now I demonstrate the wonders of Rake. Rake is short for “Ruby make,” with make being a way to script processes using the terminal (usually UNIX/LINUX wizards use this).
If you’ve been kind enough to check out my previous testing blogs, and you’ve looked at the Github project for them, you’ll noticed that there are fancy “pod install” commands you have to run to get the project up and running. While you can install Cedar globally, the demo project I put up on Github uses CocoaPods to install the Cedar test framework. Since I will continue to use this Github project in future blog posts, let’s get Cedar up and running using CocoaPods.
Since we covered the easier stuff in the previous post, I will jump right using testing techniques that are a tad bit more useful. For this blog post, let’s focus on mock objects (or in Cedar’s case specifically, nice fakes), and very basic dependency injection.
While many of us remember the “cowboy” coding days of the wild wild development west (some of us are still living there), in this day and age of modern development, we need to provide proof that our code does what it is supposed to. We can prove the viability of our code using different testing approaches (integration testing, functional testing, etc.), but for most developers the first line of testing defense is creating unit tests.
One of the many challenges developers face besides lack of sleep (especially true for me when I walk away from my code when I’m in the middle of a problem) is when frameworks and libraries are thrown over the wall for us to consume that are a little lacking in features. While some of us have the ability to ask for additions if the frameworks are in house, some of us do not (UIKit I’m looking at you). While it’s pretty straightforward to add a utility method to a class, it’s a little bit more involved to add a property.
There comes a time in every Objective-C developers life when we question the equality of an object. Most of the time we are okay with the default -isEqual: method that is given to us with NSObject which tests for equality using the reference of the object itself. However, most of the time we would rather have the custom object’s properties and attributes define and determine equality.