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?
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 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.
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.
A little before-and-after may show you why I’m so excited about this matcher. Here’s a test I wrote before OCHamcrest 1.6:
As you can see, the test creates an array of two strings. It passes this array to the method under test, a convenience method that creates an array of MyDownloader objects. The expectation is that the resulting array will have URLString values matching the original array of strings.
What I don’t like about this test is that the verification has to go through a number of steps:
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.