Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Class method stubs only affect the exact class that's mocked #233

Open
ian-twilightcoder opened this issue Sep 5, 2015 · 7 comments
Open

Comments

@ian-twilightcoder
Copy link
Contributor

I have a superclass/subclass situation where there's a class method that's only implemented in the superclass. The class method is often called as [[self class] classMethod] (as a general pattern in case one of the superclasses decides to override +classMethod). The problem I'm running into is that stubbing +[Superclass classMethod] only works if it's explicitly called as [Superclass classMethod]. If [[self class] classMethod] is called and self is an instance of Subclass, then the original version of +[Superclass classMethod] is invoked rather than the stubbed version.

OCMock's unit test -[OCMockObjectClassMethodMockingTests testStubbingIsOnlyActiveAtTheClassItWasAdded] implies this is on purpose, but I'm not sure why. Is it possible to do something like "stub +[Superclass classMethod] and I don't care how it's invoked"? My ideal behavior would be this.
A. Superclass implements +classMethod.
B. Subclass1 does not implement +classMethod.
C. Subclass2 overrides +classMethod.
D. Class mock made of Superclass.
E. +classMethod stubbed on the class mock.

  1. [Superclass classMethod] returns the stubbed value.
  2. [Subclass1 classMethod] also returns the stubbed value.
  3. [Subclass2 classMethod] returns Subclass2's normal return value.
@erikdoe
Copy link
Owner

erikdoe commented Sep 16, 2015

The reason is not that the current behaviour is more logical or generally preferable. In fact, the behaviour used to be different. However, the introduction of verify-after-running in OCMock 3 required the introduction of dynamic subclassing on a larger scale and I found it impossible to untangle the setting and resetting of classes taking inheritance into account. So, I switched to the current behaviour.

@erikdoe erikdoe closed this as completed Sep 16, 2015
@ian-twilightcoder
Copy link
Contributor Author

Could this be kept open for consideration then if the current behavior was more a necessity than something desired?

@erikdoe erikdoe reopened this Sep 17, 2015
@sarat-velumuri
Copy link

Hi,
Is there any plan to address this enhancement?

@erikdoe
Copy link
Owner

erikdoe commented Jun 7, 2016

As I wrote above, this is a complicated problem, and to be honest, I still don't know how to implement this. So, unless a pull request appears from somewhere, I wouldn't hold my breath...

@sarat-velumuri
Copy link

Thank you Erik for the update.

Can you please help me if there is any other way to achieve this? I am in real need of it.
If there is no other way, is it possible for me to revert that commit in my local repo and use the feature?

Please let me know.

@erikdoe
Copy link
Owner

erikdoe commented Jun 9, 2016

There isn't a single commit to revert. This is the consequence of a significant change across the codebase. If you need the method stubbed in subclasses, you have to find the subclasses and stub the method in each class.

@sarat-velumuri
Copy link

Thank you Erik for the update

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants