Take the so-called “self=[super init] myth” brought up in an earlier version of this post. You can’t test whether it’s safe to ignore the return value of invoking your superclass’s designated initializer. The documentation says to assign it to self, so that’s what you should do; whether the frameworks you’re using rely on that to be the case is an implementation detail that can (and has) changed.

All that you can really do is test that it does behave like the documentation says. For something like designated initializer behavior that’s a bit boring; for more interesting functionality, like (say) Core Data mapping and migrations it can be quite a bit more interesting.

Regardless, though, one good way to do such testing is to write unit tests for your model, controller, and view (connection) behavior to ensure that the pieces of your application are behaving as they’re designed to. When they aren’t, then you can dive in a bit deeper to see whether it’s because of an issue with their design or with the frameworks themselves.

Still, occasionally the documentation can contradict itself. In that case, one should rely on those in a position to know to resolve the contradiction. The best way to alert them is to file a bug report.

We are only undeceived by that which, deceiving, can no longer harm.