We get feedback from the compiler. We get feedback from Test Driven Development. But what sources of feedback lie in between?
This is where linters come in. A linter goes beyond “Does the code compile?” A linter answers questions like, “Is the code idiomatic? Is it stylistically clean? Are there any red flags?”
Those of you who are regular visitors to qualitycoding.org may have already read Jon’s article outlining the life cycle of XCTestCase objects during the execution of a test suite. If you haven’t, or you want to refresh your memory, take a moment to read the original article.
Jon discusses the importance of the setUp and tearDown methods. And, more specifically, why we should be deallocating our properties in the tearDown method.
Writing a tear down method is one of those repetitive tasks. It follows a specific pattern: all properties should be set to nil. It doesn’t really require any brain power. It’s just one of those annoying tasks that you have to remember to do when writing a test.
It’s tasks like this that should be automated. And now with the Swift tear down inspection AppCode plugin, we can.
I’m always on the lookout for new tools. Are you? Anything that might increase programmer productivity is worth a look.
You know that I’m a big AppCode fan. It saves huge amounts of time. And doing so within an IDE helps me stay “in the zone.”
So I’d love to hear more from you. What are your favorite tools for productive programming? Share your tips in the comments below!
OCHamcrest matchers are predicates on steroids:
But OCHamcrest isn’t just a library of powerful matchers. It’s a framework for creating your own.
By creating a custom matcher, you create a small Domain-Specific Language. This will make your unit tests easier to write, easier to read, and self-diagnosing!
AppCode vs. Xcode: Which is easier to use for unit testing? Which gives better feedback?
I’ve written about the big improvements to OCMockito’s error reporting. But when I ran the tests, I saw striking differences between the two IDEs.
Back in Xcode 4 days, Apple’s file template for Objective-C unit tests was awkward and bloated. So I made my own.
Fast-forward 5 years to Xcode 7.3. I’m starting to write Swift. The first thing I want is unit tests — let’s create a new test suite.
Why am I not surprised that Apple’s template for Swift unit tests is filled with cruft?
Fine. I made my own.
Fast feedback is the chief benefit of TDD. Even if you’re not practicing TDD, anything that reduces the need to step through code saves a lot of time. For example, if you name your tests well, a test failure can tell you a lot just from the test’s name.
But what if you’re using a mock object? When a test fails, what can it tell you?
A hand-coded mock can tell you as much as you can code. But writing boilerplate gets old, so the reporting tends to be shallow.
And most mock object frameworks generate mocks that simply report, “Such-and-such was not invoked.”
This was also true of OCMockito. Until recently. Here are the 3 new descriptions of verification failures:
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.
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.