I want to make my blog better and more relevant to your needs and interests. To do that, I need to know more about YOU. As a result, I have created my first-ever Reader Survey.

2014-survey

Would you please take a few minutes to fill out the survey? By doing so, you will ultimately be helping yourself. Why? Because you will be helping me make my content even more helpful and relevant to you.

Your input is important to me. The survey is easy to fill out. It’s completely anonymous. And it will only take five minutes of your time.

Thanks in advance for your help.

objc.io is a monthly online magazine, with an editorial team. Each issue focuses on a particular subject, and Issue #15 is about Testing. I’m honored to be a contributor with my article “Dependency Injection”.

objc.io #15

Books

My article refers to two books I highly recommend:

  • Dependency Injection in .NET by Mark Seemann. This book is marvelous, and I need to study it more. (If you’re wondering why an Objective-C programmer is recommending a book with “.NET” in the title, you need to get out more. Learn what’s going on in other languages, and the smart folks who work in them.)
  • Working Effectively with Legacy Code by Michael Feathers. This now-classic text was instrumental to me when I first got started writing unit tests, helping me break through many conceptual barriers. Feathers boldly defines legacy code as “code without tests.”

Question: Do you have any comments about my Dependency Injection article, or any of the other Testing issue articles? Leave a comment below.

AppCode is an alternative IDE for Objective-C development. When it comes to test driven development, it’s superior to Xcode. But that’s not all. Check out the “inside-out” coding style it makes possible. In general, AppCode lets me focus more quickly on semantics and less on fiddling with source code.

Links:

Question: What other AppCode tricks do you like? Leave a comment below.

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.

XcodeCoverage - code coverage for Xcode

Hole” by Bart Everson, used under CC BY 2.0 / Cropped

(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!

September Update: I capped things off with iOSDevUK and NSSpain.

Update: Apple took this to heart, and fixed things in Xcode 5.1.

Bug or feature? “You have to call __gcov_flush() to collect coverage data with the iOS simulator.” According to Apple, this is a feature. But not if you actually want to measure your code coverage.

Code coverage ERROR: no .gcda files found

But it worked on Xcode 4 / iOS 6…

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, after all.

There, I said it.

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 with his own follow-up screencast, demonstrating:

There’s a lot of interesting stuff here. But I also want to acknowledge that this screencast changed my mind about dot notation. Yes, really!

What are your thoughts about ReactiveCocoa, Kiwi, or AppCode? Leave a comment below.

NSBrief is a fun and informative podcast about Cocoa “developer-y topics.” I’m honored that I had my moment of glory on Episode #97: Jon Reid.

NSBrief

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 I’d like to recommend two in particular relating to testing:

Do you have any questions about anything we said during the podcast? Leave a comment below.

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!

UIActionSheet example

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…