So you’ve tried to increase iOS unit testing in your organization.
Maybe you tried to lead by example, hoping others on your team would follow suit. Or maybe you tried to increase your own testing.
Either way, your efforts fell flat. Your new emphasis on testing was barely noticed, and eventually forgotten. Leading by example is key to introducing a test-driven culture to your organization. But it’s no good if no one sees your example.
If only there were a way to bring your tests in from the shadows, placing them front & center.
There is. It’s no silver bullet, but it’ll help. And it’s easier than you may think.[This post is part of the series TDD Sample App: The Complete Collection …So Far]
I have a confession to make. My code is clean. My email inboxes are nearly at zero. But my physical inbox, on my nightstand?
Oy vey. I don’t want to show you. Instead, here’s an image illustrating what my physical inbox feels like, when I stop to notice it:
It’s not like I mean to have a pile of clutter. But you know, it’s death by a thousand cuts. One item at a time, that corner of my life is becoming more cluttered.
As a protection mechanism, I’ve even stopped noticing the pile. But many of those items were put there by my wife, to make it clear that that item is my responsibility.
How about your source code?
What if there were a way to get feedback on your code every time you compiled?
As developers, we depend on feedback to tell us how good our code is. That’s why I’m passionate about unit tests and TDD: they give me feedback quickly, and the feedback is so good that I’ve come to depend on it. Unit tests are faster than manual testing, and faster than acceptance testing. But there are forms of feedback that are faster still…
I’ve seen crashers ship which could have been prevented altogether, simply by enabling more compiler warnings. The sooner you detect a problem, the cheaper it is to find and fix. So let’s all dial up our Xcode warnings to catch more problems at compile time. …But how high should the warning settings be?[This post is part of the series TDD Sample App: The Complete Collection …So Far]
What’s a technical skill that will increase your effectiveness, but isn’t programming? How about: being efficient your source control system’s command-line interface? Even though I’ve used Git for a while, there are some things I’ve picked only recently that have made me more efficient.
Did you ever have a time when you were using a hammer, slowly driving in one nail at a time? Then along comes someone with a nail gun and BAM BAM BAM, they’re done! …That’s what comes with using a more powerful tool. We use source control systems every day, yet many of us slowly click on things in a graphical UI, or slowly type out commands in their entirety.
The more you equip yourself with good tools and learn to use them well, the better you’ll be able to stay “in the flow” of development. For example, time spent learning keyboard shortcuts for Xcode quickly pays off. In the same way, the better you can use Git (or whatever you use for source control), the more it gets out of your way, letting you concentrate on the actual coding.
So I want to show you 6 simple things you can use to improve your Git workflow — a set of Git power tools. These tools generally involve one-time setup (except for one that is a fun, game-like tutorial). Put these tools to use, and you’ll find you can get more done, more quickly.
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.
Are you interested in the AppCode templates I use?
Question: What other AppCode tricks do you like? Leave a comment below.
(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!
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… 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.
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 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.
Whenever test code has repeated patterns, there’s an opportunity to make it more expressive and readable. This can sometimes be done by creating a new OCHamcrest matcher.
“hasProperty” is something of a misnomer, because it’s not just for properties. Any method, without arguments, that returns an object, is fair game. But I couldn’t think of a better name; I think it communicates well. Let’s take a look at a before-and-after code example.
Unit test code is often tricky to read. Test output is often hard to read. There’s got to be a better way.
Hamcrest is an important tool for writing unit tests. It’s now a standard feature of jUnit, and lets you build test expressions that are expressive and readable:
I’ve ported Hamcrest to two languages:
Since Quality Coding focuses on iOS development, I’ll write about OCHamcrest on this blog.
…But Justin Shacklette beat me to the punch! His post Intro to OCHamcrest is a nice overview. He introduces the many “matchers,” illustrating them with code samples. He even makes special notes to call out areas that might trip you up.
I’ll eventually write about OCHamcrest myself. Until then, go check out Justin’s writeup.
Any questions about OCHamcrest? Leave a comment below.
Update: Apple took this to heart, and improved the unit test template in Xcode 5 and greater.
Xcode 4 has a File Template Library for creating new files. It includes a unit test template called “Objective-C test case class.”
Don’t use it.
Wouldn’t you like your unit test development to go faster? Let me give you a better file template.
Apple’s template puts cruft in your project. Cruft slows you down.
What’s wrong with Apple’s unit test template? Depending on which version of Xcode 4 you’re using, the template can be unnecessarily complicated, due to a distinction between logic tests and application tests that no longer exists.
But the template’s description reveals an ongoing problem: “An Objective-C class containing an OCUnit test case with a header.” A header? What for?
Xcode unit testing has come a long way for iOS development. How does it measure up? I wrote this post when Xcode 4 came out, but many of the pros & cons still apply. For unit testing, Xcode has come a long way, but there’s still a lot of room for improvement.
Before Xcode 4, I recommended adding third-party unit testing frameworks such as Google Toolbox for Mac (GTM) and GHUnit. But with Xcode 4, the out-of-the-box tools are mostly sufficient. I say “mostly,” because it’s still a mix of the good, the bad, and the ugly. But, mostly good! Read on for a rundown of the pros and cons…