erikdoe/ocmock — pull request #64 by carllindberg (2014-02-03 23:52:20+00:00)
Title: Support -andForwardToRealObject when stubbing/expecting class methods

Support -andForwardToRealObject when stubbing/expecting class methods.

With this implementation, it requires an explicit -classMethod be invoked before andForwardToRealObject, rather than also supporting the mode where an unambiguous class method is determined later. Not ideal but we don't know the latter situation until later in the process, which is after the invocation handler needs to be added.

One option would be to unconditionally always add the handler, then move the invalid-andForwardToRealObject-checking logic inside the handler itself (if the target is a proxy and not an OCPartalMockObject, then raise the exception). This means the error is an actual runtime call rather than getting flagged during the mock setup. It will trigger if andForwardToRealObject is used on a non-partial mock and non-class method and that method is actually called, but if not called it would leave the error in the mock setup unflagged, which could be more surprising if the runtime changed to call the method. This does work, but unsure if not flagging the error immediately is a big deal or not.

Another option would be to always add the handler, but then flag in OCMockRecorder that andForwardToRealObject had been called, then later on when the method signature is supplied check to see if the forwardToRealObject is valid at that point (partial mock or class method). This also wouldn't be too hard, though would probably need a new method which OCPartialMockRecorder could override since that would involve changing logic which is currently shared by the two classes. Not hard though.

So.... which option does people think is best? The pull request as posted, or option 2 or 3 as mentioned above? I'd be happy to update the pull request (or post others) with the other options.