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?
Subscribe to Download these FREE Code Snippets
Languages: Swift and Objective-C
IDEs: Xcode and AppCode
You’ll get our newsletter on Clean Code techniques for iOS developers. And you’ll get instant access to these code snippets!
Test-Driven Development: Does it work for iOS apps?
Short answer: Sure! Here’s an example:
Longer answer: “eBay Instant Sale” went live in the App Store two days ago. I can’t share the source code with you, of course. But here’s the unit test coverage:
It was written almost entirely using TDD. Sometimes tests weren’t written first (especially the code by a new engineer I couldn’t mentor because I was away). But test first or test last, they got written.
“That’s fine,” you may say, “but what benefit did they have?” If you’ve never done TDD, you haven’t felt the empowerment it brings. Read the following statements twice:
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…
Hello, and welcome to Quality Coding — a place to share tools, tips & techniques for building quality into iOS development.
I’m Jon Reid. By day, I work as a code monkey in Silicon Valley, developing iOS apps at eBay (and of course, everything on this blog is my opinion, not that of my employer, etc., etc.). By night, I watch Dr. Who with my wife and teenage kids, practice electric bass for my faith community… and code for fun, working on tools like OCHamcrest and OCMockito to help me with my work.
I intend to cover topics here ranging from Xcode settings to continuous integration. My expertise lies in Test-Driven Development, so expect to see that as a major theme of this blog.