XcodeCoverage - code coverage for Xcode

The Xcode 5.1 update proved to be more exciting than I anticipated. And I mean “exciting” in the sense of “breaking the tools I use.” xctool stopped working, and so did my code coverage scripts.

(Lesson learned: Always download the developer preview and give it a try, before running Software Update…)

Facebook updated xctool. And I’m happy to say that XcodeCoverage now works with Xcode 5.1! Thanks to my coworker Mike Maietta for figuring out how to create a wrapper around the new gcov so that it continues to work with lcov.

Your coverage numbers may change slightly as you use Xcode 5.1 — but not much. And we don’t need the __gcov_flush() workaround anymore. Hurrah! Continue Reading…

For my European readers: I have two speaking engagements coming up in January 2014. The first is with Mobile Central Europe in Warsaw on January 11. I’m honored to be part of this brand new developer’s conference! Here’s the cool conference trailer:

Then after an eBay iOS Developer Meeting in Berlin on January 13 (for eBay Inc. employees only), I’ll be speaking at eBay Tech Talk in Berlin on January 14 (open to the public).

I hope to meet some of you soon!

Code coverage ERROR: no .gcda files found

But code coverage worked on iOS 6…

Update: This workaround is no longer needed for Xcode 5.1. But if you use my XcodeCoverage scripts, see Code Coverage Fixed for Xcode 5.1

Code coverage… oy vey! Back in the days of running on iOS 6 using Xcode 4, measuring code coverage for unit tests was fairly straightforward. A set of coverage scripts I published made it easier still.

Then along came iOS 7 and Xcode 5. Coverage still worked if you continued to run on iOS 6. But on iOS 7, you’d get “ERROR: no .gcda files found” indicating that coverage data wasn’t being captured. “Well, maybe I need to switch from SenTestingKit to Apple’s new XCTest framework.” Nope, that didn’t help. Continue Reading…

Dot notation is okay

Or “How I Learned to Stop Worrying and Love Dot Notation”

I’ve been a staunch opponent of dot notation. I saw it as obscuring messaging, and encouraging programmers to violate the Law of Demeter through chained dots. I went so far as to characterize dot notation as an Objective-C code smell.

So it may surprise you to learn that I’ve recently adopted dot notation in my code! Here’s how it happened…  Continue Reading…

Remember my iOS Model-View-Controller TDD screencast? Eric Baker took it a few extra steps. He made an excellent follow-up screencast that demonstrates:

Without further ado… heeere’s Eric!

I thought about posting my thoughts about the tools Eric demonstrates… but I didn’t want to dominate the conversation. What do you think?

I will share this much up-front: Look for another post about how this screencast changed my mind about dot notation!

NSBrief Podcast

June 10, 2013 — 2 Comments

NSBrief

NSBrief is a fun and informative podcast about Cocoa “developer-y topics.” I’m honored that I had my moment of glory, Episode #97: Jon Reid! Host extraordinaire Saul Mora and I had an hour-and-a-half conversation about iOS unit testing, test driven development, and such.

There are a quite a few other episodes, but two in particular I’d like to recommend:

Check them out. Subscribe to NSBrief! Then in the banner at the top of the NSBrief site, click on “Glassboard” to join the discussions taking place on a private social network.

UIActionSheet example

People assume you can’t write unit tests for user interface code. That just ain’t so. I’ve already shown you how to do UIViewController TDD. Can we do the same for UIAlertView and UIActionSheet? Sure!

This time instead of a screencast, I’ve put my code on GitHub, because you’ll want to incorporate some classes into your tests. Go to my iOSAlertViewActionSheetUnitTesting repository. Continue Reading…

CocoaConf vs. WWDC

April 22, 2013 — 2 Comments

cocoaconf

I just wrapped up a great weekend with CocoaConf San Jose. I’ve gotta say: if you’re looking to maximize bang for your buck, save the money you’d spend on WWDC and consider CocoaConf instead!

First, there’s the stress of trying to get a WWDC ticket. Then the expense. Sure, there are all those great talks, but Apple makes the videos available to registered developers. I think the main reason to continue going to WWDC is if you’re really desperate to get help in the Apple labs.

I’d never been to another iOS/Mac developer’s conference before this past weekend. I was impressed by:

  • The small size. With only a hundred developers, there were many opportunities to build relationships, even with the speakers.
  • The speakers. This is a class act of experienced people. Many of them are published authors. They’re there because they’re passionate about their craft.
  • The food. Remember when WWDC food used to be decent, before the iOS-induced population explosion? This was like that, only better. Much better.
  • The duration. My brain is full by the third day of any conference. CocoaConf wisely stops there.
  • The price. Way cheaper.

I came away having learned good stuff. But maybe just as important, I made genuine human connections. (Good luck doing that at the great cattle-herding of WWDC.)

CocoaConf is a traveling conference, hitting up several cities in the U.S. You owe it to yourself to check out the one nearest you.

Use good #import order to prevent incomplete headers

In #imports gone wild! we looked at the problems caused by having too many #import directives. But it’s also possible that you have too few, resulting in bad header files — especially if you don’t pay attention to #import order in your .m files.

Minimal and complete

When it comes to imports, header files should satisfy these two conditions:

  • They should be minimal
  • They should be complete

“Minimal” just means a header file should import no more than it needs.
“Complete” means the header file imports everything that needed to compile it. Consider Continue Reading…

The UIViewController TDD screencast ended with all the code in the view controller. Unfortunately, this is where many iOS programmers leave things! In part 2, we pick up from there and TDD to extract a model class, which the controller observes. You’ll see it evolve into true Model-View-Controller, driven by unit tests.

In particular, you’ll see how to TDD:

  • a model that posts notifications when it changes, and
  • a controller that observes those notifications.

Questions?  Continue Reading…