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.

You just finished reading "CocoaConf vs. WWDC" on Quality Coding. I'd love to hear your thoughts about it!

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

If removing foo.h (or changing the order) causes bar.h not to compile, then bar.h is not complete.

Incomplete headers

Poor #import order masks dependencies

One way to have an incomplete header is by relying on precompiled headers. In particular, just because the precompiled headers include a particular header doesn’t mean you can omit it elsewhere.

Another way to have an incomplete header is with a poor #import order that masks dependencies. In C-based languages, programmers often begin their implementation files by including the most general headers from the largest scope. They work down from there, until they reach the most specific headers:

1. system headers
2. other headers
3. finally, the unit’s own header

This is backwards. Consider a header foo.h that depends on <QuartzCore/QuartzCore.h>. If foo.m imports QuartzCore first, then other stuff, then finally gets to its own header, you may not feel the need to import QuartzCore in foo.h.

…And this will break for the next programmer who comes along and just imports foo.h.

Good #import order

The solution is simple: reverse the order! Start from the most specific, then work towards the most general. Most importantly, include your own header first. Large-Scale C++ Software Design by John Lakos is the only book I know about “physical design” — how to arrange source code into files. The author states,

Latent usage errors can be avoided by ensuring that the .h file of a component parses by itself – without externally-provided declarations or definitions… Including the .h file as the very first line of the .c file ensures that no critical piece of information intrinsic to the physical interface of the component is missing from the .h file (or, if there is, that you will find out about it as soon as you try to compile the .c file).

In other words, by including your own header first… if the header is not complete, you will fail fast!

Here’s what I do. If I’m writing foo.m, I first import foo.h. I keep this separated from other imports by a blank line. All the others follow, in sorted order:

Sorting helps me find duplicates. It also puts angle brackets imports <> after quoted imports, so that the most general headers come last.

Questions? Comments?

Photo by Jason Thomas (license), adapted by Jon Reid

You just finished reading "Why #import Order Matters" on Quality Coding. I'd love to hear your thoughts about it!

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? 

Links:

• My review of Graham Lee’s book Test-Driven iOS Development
• Why AppCode is Nice
• TDD: 4 questions that will help you create the simplest thing that could possibly work by Roy Osherove

“Do it now” sound by freesound

You just finished reading "iOS Model-View-Controller TDD [Screencast]" on Quality Coding. I'd love to hear your thoughts about it!

Is TDD worth the effort? Andy Dwelly tried applying my TDD screencasts to his iOS coding. Here’s what he writes in Some notes on Test Driven Development:

At first progress was almost painfully slow.

Yup. It seems like there’s a lot to learn. The real barrier, I think, is that there is a lot to unlearn. And so, when you first get started with Test Driven Development, your productivity will take a big hit. This is normal! But if you’re willing to press through the learning curve, your productivity will increase again — in ways you may not have experienced before… 

TDD: Immediate Benefits!

I would normally expect to write the final line and then fire up the debugger to get it to actually work.

Except that it did just work.

I experience this fairly regularly, even when I TDD a new view controller.

I think at this point, if I’d been asked anything about the issue of code quality I would have claimed that the actual code produced was marginally better. My TDD code certainly handled errors and failures better, but had poorer information hiding and some dependency injection that I would not normally have bothered with.

Then my tests found a bug that I don’t think I would have spotted until the code hit the field.

Do the math: What is the cost of a fixing a defect vs. preventing a defect? Even though TDD takes more time up-front (when it’s just the developer’s time), it reduces time later (when more people are involved). I think there’s enough evidence out there to make this claim: Once you make it over the learning curve, your time-to-market will be the same — but with many more benefits!

TDD: Limitations?

I’m still of the view that trying to do a lot of UX tests using TDD is hard.

What Andy hasn’t experienced yet is the real powerhouse that TDD enables: refactoring. To me, this is the greatest benefit of Test Driven Development. It’s a shift of emphasis, from “prevent bugs” to “empower change.” And that’s why I’m vigilant about unit testing view controllers, down to the nib connections. Where some people say, “I don’t think that last bit is worth the effort,” my reply is, “It’s often not that hard. Why would you turn down the chance to automatically check your code?”

So Andy is still early in his iOS TDD journey. He’s still approaching it with some skepticism. But it didn’t take long for him to experience some of the benefits! Go read his account.

Then I’d like to hear from you: Is TDD worth the effort? What are your questions / concerns / reservations / experiences?

Photo by Roger Carr (license), adapted by Jon Reid

You just finished reading "Is TDD Worth It? A Testimonial" on Quality Coding. I'd love to hear your thoughts about it!

Sometimes it’s OK to unlock things for greater testability

In my UIViewController TDD screencast, I put IBOutlets and IBActions in the header file. This made them accessible to unit tests, but I knew it would raise questions:

@qcoding This seems like it complicates the question of whether or not actions and outlets truly belong in the public interface or not.

— Aengus McMillin (@Wizecoder) January 22, 2013

It’s a fair question. There’s a tension between information hiding (don’t reveal things in the interface) and testability (certain things need to be exposed). Exploring that tension leads me to apply the Extract Class refactoring in places I hadn’t considered before.

Objective-C classes don’t have anything that’s truly private, but it’s understood that if something isn’t published in the header file, hands off. As of Xcode 4, you can define outlets and actions in the implementation file, effectively hiding them. More hiding is good. But my screencast example works against it, what gives?

There is a way to have it both ways, a technique I used to use. I’ll show you how, then explain why I stopped using it.

How to hide (but still access for testability)

Let’s use the TDDCounter example from the screencast, but hide its outlets and actions. The interface shrinks:

The outlets move to a class extension in the .m file:

That hides things. How do we re-expose them for the tests? By adding a class extension to CounterViewControllerTest.m:

Tests pass — this is a successful refactoring. …So what’s the problem?

Why I avoid this technique

I once used the technique above. And if the thought of relaxing information hiding really bothers you, go for it. …But before you do, let me explain why I avoid it.

DRY

“Don’t Repeat Yourself” is one reason I’m no longer comfortable creating a testing category. Those repeated declarations? They make test maintenance a pain. They slow down refactoring, especially renaming.

Since enabling refactoring is a primary purpose of unit tests, slowing down refactoring is especially counter-productive. For me, it’s a bigger problem than exposing too much.

Encourages testing of privates

When I’ve used categories to make hidden outlets and actions accessible to tests, a curious thing happened: Other properties began sneaking in to join the outlets. Other methods began sneaking in to join the actions. The temptation is strong. Just use the word “testability” and it’s easy to justify!

With TDD, it’s sometimes hard to come up with a good test that’s small enough to achieve in a short time. But before you decide to TDD a hidden method, or verify it through a hidden property, pay attention. Another class is almost certainly trying to get out.

With legacy code, however, one adds unit tests after the fact. I may not feel comfortable extracting a class quite yet, because I don’t yet have the coverage I need for refactoring. So I’ll take the interim step of exposing certain methods and properties for testing. Their presence in the public interface is a reminder to me of unfinished work. And it’s easier to identify the class that wants to be extracted once enough previously hidden methods and properties are exposed.

OK, but what about outlets and actions?

For the most part, exposing IBOutlets and IBActions in the header file is a matter of expedience: testability trumps hiding. It would be easy to leave it at that, shrug, and move on.

But hold on. What if, as with legacy code, too many outlets and actions in the public interface is a reminder of unfinished work?

Imagine that the view I show in the screencast is more complex. Let’s say that it’s part of purchasing an item, and that the count determines the number of items to put into your shopping cart. So the view will also have item images, description, pricing, etc. Even if we extract the business logic, typical iOS code puts all the views together into one giant view controller.

Do you see the opportunity to Extract Class? We can pull out countLabel, plusButton and minusButton to a subordinate view controller, separate from the other UI aspects of purchasing an item!

So when you write unit tests against a view controller (whether test-driven or test-after), don’t worry about hiding the IBOutlets and IBActions. Testability leads us to expose them, and exposing them may reveal that subsets of views we can group and extract. This is one way testing helps us discover better designs.

Photo by Darwin Bell (license)

You just finished reading "Testability vs. Information Hiding" on Quality Coding. I'd love to hear your thoughts about it!

In my screencast of UIViewController TDD, I used an example of incrementing a counter and couldn’t help but give a slight aside: “We’ll increment it… ++count, instead of count++, please.”

<rant>
I blame Apple for propagating poor incrementing style. Programming with Objective-C starts with the statement, “[Objective-C is] a superset of the C programming language.” But every example they give of incrementing a value uses someInteger++, ignoring the fact that C has two different increment operators!

• Post-increment: count++
• Pre-increment: ++count

The Wikipedia article Increment and decrement operators gives clear examples of the difference.

What performance impact will it make? None. The extra code for post-increment semantics is probably optimized away by today’s compilers. Even if it’s not, it’ll still have almost no impact. So what does it matter?

It matters to the reader. It matters because it shows a lack of familiarity with the language’s operators, which doesn’t fill me with confidence in your code. It matters because Objective-C Is Still C (Not Java!)

Say what you mean, rather than relying on side-effects.
</rant>

You just finished reading "++count vs. count++: Do you know the difference?" on Quality Coding. I'd love to hear your thoughts about it!

This screencast focuses on the question I get the most: “Do you do test-driven development for view controllers?” It’s clearly a roadblock for many people. This screencast should remove that roadblock.

It also answers the question, “Is it worth doing?”

I cover:

• Three types of unit test verification
• View controller unit tests: the trick
• TDD demo
• How UIViewController TDD can actually help you code faster

Any questions?

…I did mess up something pretty big, and I don’t mean the nib and coding mistakes, which the unit tests successfully caught. I mean my failure to test the labels of the two buttons. I was so eager to show you how to test button behavior, that I forgot about how important it is to test button labels. So my apologies there, but I thought it was more important to get the information out than to try again.

Links:

• The first screencast, an Intro to Objective-C TDD
• My Resources page, where you can get OCHamcrest and my test case template
• Subscribe to this blog and I’ll send you my test code snippets
• Chris Hanson’s original blog post from July 2006 describing the trick
• Non-TDD UIViewController demo counter-ios, the basis for my example

See also: Testability vs. Information Hiding, a follow-up discussion about whether to expose outlets and actions in the interface.

“Palette” photo by petra** (license)

You just finished reading "UIViewController TDD [Screencast]" on Quality Coding. I'd love to hear your thoughts about it!

My first screencast! It was sparked by a Stack Overflow question that said, “All the examples of unit testing I read about seem to be extremely simple and trivial.” The question asks how to write unit tests for a piece of sample code. What’s interesting about this problem is that it uses NSUserDefaults.

I cover:

• What to do with an external object (in this case, the NSUserDefaults singleton). Dependency injection to the rescue!
• My basic setup: OCUnit + OCHamcrest + OCMockito (along with my test case template and test code snippets)
• The 3 steps of “The TDD Waltz”
• We TDD our way to the desired functionality

Any questions? I’d love to hear your experience with this screencast. 

Links:

• The Stack Overflow question. My original answer illustrates setter injection, as opposed to the (better) constructor injection of the video.
• My Resources page, where you can get OCHamcrest, OCMockito, and my test case template
• Subscribe to this blog and I’ll send you my test code snippets
• AppCode, an alternative IDE with much more automated refactoring than Xcode
• Clean Coders video series by “Uncle Bob” Martin

See also: UIViewController TDD [Screencast]

You just finished reading "Intro to Objective-C TDD [Screencast]" on Quality Coding. I'd love to hear your thoughts about it!

Measure your code coverage to find unit testing holes

One of the first things I do when working on any Xcode project is set up code coverage. If the coverage shows a hole, I know that area is lacking unit tests.

(Be careful, the opposite isn’t true: Just because some code has been touched by unit test execution doesn’t mean it’s actually covered. If altering the behavior of the code causes a test to fail, then you know it’s covered.)

Many people use CoverStory, a a code coverage browser app written by my friend Dave MacLachlan. Others use gcovr to integrate code coverage into their Jenkins continuous integration. Me, I use lcov because it lets me exclude third-party libraries from the measurements before generating an HTML report.

When a project is built from the command-line with xcodebuild, it places build artifacts into a “build” folder, kind of like the old days. But I want to measure coverage of unit tests as I run them from Xcode itself. This complicates things because build artifacts go into some obscure DerivedData subfolder. I solve this by having the build process export some of the project’s environment variables to a file. I’ll show you where to get the shell scripts I use to do all this.

Download the code coverage tools

I have a GitHub repository called XcodeCoverage. You’ll probably want to make some per-project changes. So if you use git for your projects, think about how you want to manage your fork – branch – submodule workflow.

Place the XcodeCoverage folder in the same folder as your Xcode project.

Then download lcov-1.10. Place the lcov-1.10 folder inside the XcodeCoverage folder.

Also (if you haven’t done so already) go to Xcode Preferences, into Downloads, and install Command Line Tools to get Xcode’s coverage instrumentation.

Set up your project

First, I assume you’re using Xcode 4.5. If so, you’re in luck: It’s easy. (Code coverage used to be a little more complicated in earlier versions of Xcode, as Claus Broch describes in Code Coverage with Xcode 4.2 and Code Coverage and fopen$UNIX2003 Problems.)

The first steps are the same, regardless of what coverage tool you use. Select your project, and go into its Build Settings. (I like to make these changes at the project level so that they’ll apply to all targets.) Find the “Generate Test Coverage Files” setting. Spin down the disclosure triangle to reveal your configurations. Enable this settings for your Debug configuration:

Do the same for the “Instrument Program Flow” setting:

So far, so good. Now let’s add the extra step so my scripts can get the project’s environment variables.

Select your primary target, and go into its Build Phases. Click “Add Build Phase” at the bottom, selecting “Add Run Script”. Edit it so it runs XcodeCoverage/exportenv.sh:

This last step has tripped up some people. If you use OCUnit — where the the main target is executed with tests injected — make sure you add the script to your main target (your app or library), not your test target.

On the other hand, if you use a different testing framework that depends on a separate testing app, then add the script to your test app, not the main target.

Run!

Now we’re ready for the good stuff. Run your unit tests.

Open a Terminal window, and cd to your project’s XcodeCoverage folder. Once the tests complete, run my getcov script:

Things will fly by. Eventually, a browser window should open. Now you can see your code coverage!

Change test code, then re-run

We measure code coverage to find the holes in our tests. So now let’s say you’ve added some new tests, and want to measure the coverage. As long as you haven’t changed your production code, the quickest way is to clean out the coverage data and re-measure. To do this, run the cleancov script:

With the previous results zeroed out, now we can re-run the tests, then do getcov again.

Change production code, then re-run

Time has passed, and you’ve made changes to your production code. When you decide to measure code coverage again, you should clear out earlier build artifacts. (Leftovers confuse lcov.)

To do this, hold down the Option key in Xcode’s “Product” menu. Select “Clean Build Folder”.

Now you’re ready to re-run the tests, followed by getcov.

Modify the scripts

There are two places in the XcodeCoverage scripts you may want to modify for your project:

First: In the envcov.sh script, LCOV_INFO determines the name shown in the report. By default, the name is Coverage.info. But if you want to maintain coverage reports for multiple projects, it would be best to change this name to match the project name.

Second: If your project uses third-party libraries, you’ll probably want to exclude them from code coverage measurements. You can do so by editing the getcov script and changing the exclude_data() function.

What I do is put all third-party libraries into a folder named ThirdParty. Then I exclude the pattern "ThirdParty/*" using lcov’s --remove command.

Let me know

Let me know how it goes! Do you have any questions, about XcodeCoverage in particular, or about code coverage in general?

Photo by Salim Virji (license)

You just finished reading "How to Measure Code Coverage in Xcode" on Quality Coding. I'd love to hear your thoughts about it!

Book overview

Chapter 1 starts off with a surprising answer to the question, “Why write unit tests?” Why, to make more money! It shows how the traditional handoff-to-QA form of testing comes from the waterfall model of development, and how the cost of fixing defects increases with each phase of the waterfall.

Chapter 2 lays out the principles of Test Driven Development: test first, writing “Just Barely Good Enough” code that satisfies the test, and refactoring. But it also describes an important principle from Extreme Programming: “Ya Ain’t Gonna Need It,” or YAGNI. Basically, code only what you need to. This keeps production code simple, and avoids wasting time writing code that won’t have any effect.

The book goes on to introduce unit testing by showing how one might write tests without a unit testing framework — the old-fashioned way! Then we get an overview of the more common tools. Finally, we hit the meat of the book: a full example of creating an iOS app using TDD, spanning five chapters.

My a-ha! moments

The big example not only demonstrates TDD, but also shows how the Single Responsibility Principle improves design. I had two big a-ha! moments reading this code:

1. All model code I’ve seen includes code to build that model from XML or JSON data. Graham’s code demonstrates the power of separating model construction from representation. This is a big deal not just for improving cohesion. I’ve run into a model that assumes it’s built from XML, only to find a case where it might be built from JSON instead.
2. All table code I’ve seen takes the table data source code and the table delegate code, and lumps it all together with the overall view controller. This is normal even when the view controller isn’t a UITableViewController. Graham’s code goes against the flow by pulling data source and delegate into a separate class. This allows you to use same view controller for different tables.

Where I differ

I do want to point out one thing in the book that is incorrect, and another where I disagree.

Unit test bundles should link just fine

After writing the very first test, there’s a need to create the Topicclass. On p.68 it says,

Add a new NSObject class called Topic to the project. When Xcode asks which targets to add the new file to, check both the app target and the test bundle target. (This is required to work around a problem with unit test bundles: They don’t link symbols from their host apps correctly.)

That was once true for iOS development with Xcode 3. But with Xcode 4, Apple brought iOS unit testing in line with Mac unit testing: Xcode links the test bundle against the app, and injects it into the running app. If the test bundle is unable to link, there’s a problem in the build settings. Make sure “Symbols Hidden by Default” is “No” for your app’s Debug configuration.

Update: Graham Lee says, “Sadly, at the time of publication, the linker problem still needed to be worked around.”

Is method swizzling worth it?

The part where I disagree is the author’s use of method swizzling. He acknowledges that some may consider method swizzling ”too clever,” and in my case, that may simply be because I haven’t used it yet. But let’s look at the two cases where he felt the need for swizzling.

First, on p.151, he’s trying to come up with a way to TDD that viewDidAppear: call its superclass. For me though, this feels like overkill because the “invoke super” idiom is well-ingrained in iOS developers. In particular, I don’t want to make testing look overly convoluted to my coworkers, whom I am trying to encourage to write tests. If I need to soften strict TDD to get them to adopt it at all, I’ll do so.

Still, I do have to say I’ve wondered how to enforce “invoke super” from a test. For idiomatic methods like viewDidAppear: I don’t think this is a big deal. But I may run into another method where it’s less obvious, and needs a test to verify it. Then I’ll know to pull method swizzling out of my toolbox.

The other case where the book uses method swizzling is on pp.154-156. The swizzling replaces a method normally invoked by a notification with a category method that records the notification. The tests verify that the class is observing a notification. But Michael Feathers’ book Working Effectively with Legacy Code shows a different way to replace methods: Subclass and Override.

• In the test code, create a special subclass that is only for testing. (For a class named Foo, I create a subclass named TestingFoo.)
• Write your test to use the testing subclass.
• Override the method.

It’s that easy! And this approach works in any object-oriented language — no swizzling required.

Update: Since writing this, I got into a situation where I needed to write a unit test for code that is tied to a singleton. Can you guess how I altered the singleton for testing? That’s right, I copied Graham’s method swizzling technique straight out of the book! I’d still consider it an unusual tool to be avoided if possible, but method swizzling is definitely part of my toolkit now.

Update 2: OK, I’ve had to use Graham’s technique more than once now. I eat humble pie. As Graham told me in a tweet, “everyone says that’s a gross hack until the moment it solves their problem ”

Conclusion: Test-Driven iOS Development is worthy

The book concludes with an overview of coding principles that emerge from TDD, including:

• Design to Interfaces, Not Implementations. This is more important for hand-rolled mocks, because it lets you easily substitute fakes. I find it less important when using mock object frameworks like OCMockito, because the generated mock is pretty close to a perfect stand-in. But designing to protocols isn’t just about substituting fakes; it’s also an important way to break dependencies between classes.
• Tell, Don’t Ask. This is a powerful tool for TDD, with a number of different ways to approach it. I use constructor injection, setter injection, injecting a factory, or factory methods which I subclass-and-override. It all depends, and I sometimes change my mind and switch.
• Prefer a Wide, Shallow Inheritance Hierarchy. I’d extend that beyond inheritance, to all dependencies: prefer a wide, shallow dependency graph. Again, protocols make this possible.

I give Test-Driven iOS Developmenta big thumbs-up. It fills an important hole in TDD examples, and shows how improved designs emerge from good TDD. Pick up a copy… but don’t just read it! The act of typing someone else’s code actually reinforces the concepts in your head. And these are concepts that will serve you well.

You just finished reading "“Test-Driven iOS Development” Fills a Big Hole" on Quality Coding. I'd love to hear your thoughts about it!