-
Notifications
You must be signed in to change notification settings - Fork 514
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
Support setting expectation or stubbing methods on toll-free bridged objects. #61
Comments
As I mentioned in the previous issue, there is no obvious way of doing this. Any partial stubbing of real objects requires swapping out the method implementation at run-time which just isn't possible to do safely with toll-free bridged objects. I'm not sure I really understand the use-case for this though; as a general rule of thumb, you should aim to only ever stub and mock types you own, which would preclude the need to stub native Foundation objects. Why do you need this? |
Not feasible, if you were unlucky it might seem to work when you try. Even stubbing and mocking Apple provided Objective-C types or types where you perform your own shenanigans with method implementations is a fragile exercise. The implementation that is there tries to be smart about it and should cover the basic cases, but simply cannot account for all the different scenarios where internal swizzling is taking place. Like Luke, I'm curious as to when doing it would actually be desirable. |
Matt: if you'd like to explain why you feel you need this, I'd be happy to try and help you find a better way. |
Okay. Sorry for the late reply. I would like to set expectations & stub methods on objects of class NSString, NSArray, etc. because: Let's imagine I write a category on NSString to add the instance methods:
To spec Also, RSpec lets me set expectations and stub methods on String & Array. |
I'm struggling to see why on earth you'd want to test like that. This isn't really the way to use mocks/stubs. Mocks are useful when you have objects playing clearly defined roles interacting with each other. They aren't so great for things like simple data transformation with no external dependencies like the above example. It strikes me that a few simple input/output tests would be far more useful and less tightly coupled to your implementation. I appreciate that RSpec let's you do these the with String and Array but that doesn't mean you should. "Only mock types you own" and "mock roles, not objects" are important rules to live by if you want to make good use of mocks. |
I read, "unit tests should test a method's external behavior rather than its internal implementation," on Wikipedia Mock Objects. And the RSPec Book says, "Even the most highly decoupled code has some dependencies. Sometimes they are on objects that are cheap and easy to construct and have no complex state. These generally don’t present a problem, so there is no need to create stubs for them." So, if I used input/output tests to test I thought a unit test was only supposed to test one unit/method at a time? P.S. I'm ordering that book you recommended off Amazon... :) |
How should I stub |
I'm not sure should I open a new issue or better to ask here. So I will start with asking here) I'm testing some network-related code and would like to stub it(@"should return NSInteger from stubbed method", ^{
NSHTTPURLResponse *mockedResponse = [NSHTTPURLResponse mock];
[mockedResponse stub:@selector(statusCode) andReturn:@200];
[[theValue(mockedResponse.statusCode) should] equal:theValue(200)];
}); Is there any way to stub method which are return for example NSInteger? Thanks in advance. |
This feature is a must for me.
The text was updated successfully, but these errors were encountered: