Which is testing framework is best?
This really depends on which day you ask me that. I’ve been working with Expecta on XCTest recently, and I like that combination, but there are things that the other frameworks appear to do better. Here’s a comparison of some key features:
Framework | Xcode Integration | Runs On: | Debugging | Notes |
---|---|---|---|---|
XCTest | Best | Both | Good | Built-into Xcode 5 |
OCUnit | Best | Simulator | Good | Built-into Xcode |
GHUnit | Add-on | Both | Good | Separate build target |
Expecta | Good | Both | Good | Matchers, supports async |
OCHamcrest | Good | Simulator | Good | Matchers |
Kiwi | Good | Simulator | Difficult? | Blocks run on OCUnit |
Note that GHUnit runs as a separate build target. This allows running unit tests stand-alone on either a device or simulator. This is fabulous for things like API tests. Not quite so convenient for Continuous Integration tests.
Apple often breaks OCUnit or its templates when a new version of Xcode is released. Caveat Emptor.
How much test coverage is enough?
As much as you can. Programmer’s often panic when asked to provide 100%, so instead I just say “test everything”.
Should I unit test views and/or view controllers?
You should test every line of code that you write. If you are inheriting legacy code, then add tests for every line of code that you plan to modify. Note: Michael Feathers defines legacy code as code that doesn’t contain tests. I agree.
Doesn’t adding unit tests take more time?
That depends on which times you are comparing. If you compare the sum of the times spent writing the code, debugging the code, and later on extending the code, then unit tests should be the hands-down winner. If you are only comparing the time spent writing the code, then clearly it takes less time to write buggy, unmaintainable code that might not work correctly.
Hi! Long time listener, first time caller!! 🙂
Do you have any insight on unit testing accessibility? I’ve been struggling pretty badly on this for some random reason and was hoping that you could point me in the right direction for guidance.
Thanks!
Craig
That might be a job for UI testing instead of unit testing. The team I work with has had really good success with KIF, but there are several other good UI testing frameworks for iOS also.
Totally agree. I use KIF-next myself with a full-out CI environment using Xcode 5 and OS Mavericks Server, thing of beauty but that’s a whole different beast. I guess maybe I should have been more specific. I’m trying to right a unit test for a view controller button per se. I want to make sure with a unit test that the buttons have accessibilitylabels and accessibilityhints set in code.
I’m working backwards in my unit testing. By that I mean that I’m taking legacy code and applying unit tests to said legacy code. I wish there was a unit testing book that explains how to work backwards with another developer/s code.!
Ah, very cool. I understand now.
Yes, the book about adding tests to somebody else’s code is Michael Feather’s book “Working Effectively with Legacy Code” (see link in top right).
iOS throws us some curve balls now and then, but most of the time it is possible to write unit tests to verify everything that the code is doing, even setting UI related properties, etc. The only exception that I’ve found is verifying who is First Responder, and that may be possible, just not worth the effort.
Be careful not to get too crazy with unit testing UI stuff. We don’t want to create fragile tests that break every time the UI is tweaked. But I think you already grok this.
I’ve not done exactly what you are trying to do, but I encourage you keep trying. I think it should be possible.