Sean McMains SeanMcTex
In the first article in this series, we set up an abstract parent class for our view controller tests and used Objective C's runtime library to create dynamically named tests for all of its concrete subclasses. This technique can save a lot of time, but we still have to remember to create a new test case for each view controller class.
Is it possible to make unit tests even more automatic? By gazing deep into the occult mysteries of the runtime system, we will answer this question and, if we're lucky, discover a little bit about love along the way. (Editor's Note: We will not actually discover anything about love.)
If you'd like to follow along with some functional code, you can download the sample project from GitHub.
Unit tests are fantastic. They make code more robust, refactoring less scary, help developers design programs well, and allow machines do more of the monkey work involved in creating a robust app.
But let's face it: unit tests aren’t always the most fun to write. Worse yet, if developers are trying to achieve high code coverage or adhere to Test Driven Development, they will often end up with a lot of repetitive tests.
This is a state of affairs that wouldn't stand for a minute in application code, but which often passes without a second thought in test code. But if we're serious about testing, this should bother us. We should strive to keep our tests as [^1]DRY as we keep our app.
How do we achieve this? In this article, we'll implement a superclass for test suites with common elements, and see how to use the Objective-C runtime to make sure those tests are named meaningfully. (Teaser: in the followup article, we'll see a technique that delves deeper into r