Quick 1.0: Better Tests for All

March 1, 2015

A few days ago, Quick reached 2,000 stars on GitHub. This is a great opportunity to explain my thoughts on Quick, and what role I think it should play in the iOS and OS X ecosystem.

iOS/OS X Testing: It's Not About Frameworks or Features

The amount of interest surrounding Quick has been breathtaking. And while I'm excited that so many developers are choosing to use Quick to test their apps' behavior, I'm even more excited that they're choosing to write unit tests in the first place.

The quality of a test suite doesn't have a lot to do with the testing framework being used. A test suite could be composed of clear, behavioral tests written in XCTest, or it could be made up of brittle, confusing tests written in Quick.

Don't get me wrong–Quick provides tools that can be used to write killer tests:

• Incremental test setup and teardown using beforeEach and afterEach
• Suite-level setup and teardown using beforeSuite and afterSuite
• Expressive assertions and descriptive failure messages, thanks to Nimble matchers like expect([1, 2, 3]).to(contain(2))
• A clear way to define your own matchers, like expect(user).to(beLoggedOut())

But these are tools for "power users". They're not essential to writing good tests. The essence of a good test is clarity:

• Clear intentions: It should be clear what's being tested. Descriptive test method names and failure messages are important on this point.
• Clear behavior: It should be easy to determine how a test works. When the setup for a test is too complex, or when it's not clear what assertions are being made, tests become difficult to reason about. I should never have to "debug" a test.

I obviously have a preference when it comes to testing frameworks, but so long as the team I work on agrees with these two points, I know we're going to be able to move blazingly fast and build a stable product.

Quick 1.0: A Lever Towards Better Tests for All

As Quick matures towards v1.0, the best way it can help people move fast isn't by adding more features. Instead, Quick should enable people to improve their code quality. Many people appear to be interested in using Quick–let's make sure doing so helps them move faster, and write better code.

To that end, I've begun adding more documentation to Quick–not just on how to use Quick, but on how to write better tests for any iOS and OS X app. Quick's Documentation directory now contains resources on many topics, including:

• How to access production code from within a test target
• How to structure tests for more clarity
• How to test things like UIViewController

I'm hoping the documentation in Quick expands to include resources on things like HTTP stubbing, mock objects, and more. People considering writing tests should have everything they need to get started just by cloning the Quick repository.

Contributions to this effort are, of course, extremely valued. Please file an issue if there's a topic you'd like to see discussed, or a pull request if you'd like to offer your take on something.