We’re pair programming, with you driving. You’re using Xcode.
I don’t say anything because I don’t want to offend you. But you’re having to do So. Much. Typing.
They say typing isn’t the slowest part of programming. But as I sit with you, I wonder… Why isn’t the code automatically appearing? We’re on a computer working in a computer language, so why doesn’t the IDE understand your intent? Why do you have to make the same changes in so many places?
Oh yeah. You’re using Xcode.
With AppCode, it feels like code flies from my head to the screen. For me, coding is manipulating ideas rather than characters. I have a coworker who would rather pair together at my computer, so that I can drive using AppCode.
What does it look like in practice? Let’s continue in my sample TDD project.
Many of you already use OCHamcrest, the matcher library I initially ported from Java back in 2008. I’m writing today to announce OCHamcrest 5.0.0, and to explain what you’ll get out of upgrading.
But first, what does it mean to jump from v4.3.2 to v5.0.0?
With the imminent release of iOS 9 and the usual fast adoption rate, many developers can finally start using APIs introduced in iOS 8. One of these is UIAlertController, which unifies code for alerts, action sheets, and iPad popovers.
So… can we write unit tests against a UIAlertController? Let’s learn some tricks for dealing with Cocoa Touch.
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.