I was referring to expected user data (e.g. a missing user defaults .plist, or a resource located on an unavailable remote connection etc.)
A missing user defaults plist is something your code should
always be prepared to handle sensibly. So should an unavailable remove resource. Malfunctioning under such common scenarios is unacceptable.
If Safari or Firefox became hopelessly lost or crashed from something as simple as missing defaults or unreachable google page, they would rightly be considered as egregiously defective.
Do you use NSAssert in your production code if you're also using STAssert in your unit test methods? Is that redundant or just a technique for being very clear about the assumptions your code is making? Perhaps I misunderstood your meaning here?
Both. NSAssert is in the actual production code. It's in the internal implementation, where unit-tests can't reach. So there might be several assertions (NSAssert) in a method, which contribute to building up the eventual result that can be externally tested.
BTW, you can use NSAssert without unit-testing, and vice versa. Neither one is an all-or-nothing proposition.
When you write code, are you inserting these checks as you go, do you write a method, then add in the checks and assertions (like one might proofread their essay before submission), or do you have some other technique (such as test driven development)?
It depends. At different times, all the above.
If I'm experimenting to find out a good way to design something, I might have only a few assertions, which are more like milestone markers that I can use to make sure things are working as expected at certain points during the experiment. During the experiment I'll make tests or "exercisers" that help gather data for making a decision from the experimental code.
After I've decided on a path to take with the design or implementation, assertions confirm that what is expected is what happens. During testing, I may see a reason to go back and add internal assertions, or move them around, or transition them to test-resident assertions (and not necessarily STAssert).
Do you have advice about how much coverage is optimal based on your experiences? Model objects, and worker objects seem like the most obvious and straightforward candidates. Controllers are trickier because you're going to run into the mock object problem that you raised.
100% coverage is best. It never happens in real life without a big investment in mockups and other testing scenarios, including stress-testing, fault injection, fuzzing, etc.. "Optimal" depends on the project: risks, costs, payoffs, time, etc.
The main thing with test coverage is to know how much you're getting. If you don't know what coverage you're getting, you have no way to tell if it's optimal (for whatever value of "optimal" is optimal for the project).
