Using OCMock, we can verify if an interaction with mock objects happen, like:
id mock = OCMClassMock([SomeClass class]);
OCMStub([mock someMethod]).andReturn(myValue);
/* run code under test */
OCMVerify([mock someMethod]);
But is this possible to verify if there's no interaction with mock object, similar to the Mockito#verifyZeroInteractions()?
The only way I know is to define a strict mock:
id mockObject = OCMStrictClassMock([SomeObject class]);
Do not define any expectation for the unwanted method, and finish test with:
OCMVerifyAll(mockObject);
It the method was called, the test will fail.
Related
I am trying to write a test case for a method in Objective-C class which returns void. The method mobileTest just creates another object of class AnotherClass and calls a method makeNoise. How to test this ?
I tried to use OCMock to create test this. Created a mock object of AnotherClass, and called mobileTest method. Obviously, the OCMVerify([mockObject makeNoise]) won't work, as I am not setting this object anywhere in the code. So, how to test in such cases ?
#interface Hello
#end
#implementation HelloWorldClass()
-(void)mobileTest{
AnotherClass *anotherClassObject = [AnotherClass alloc] init];
[anotherClassObject makeNoise];
}
#end
#interface AnotherClass
#end
#implementation AnotherClass()
-(void) makeNoise{
NSLog(#"Makes lot of noise");
}
#end
Test case for the above is as follows :
-(void)testMobileTest{
id mockObject = OCMClassMock([AnotherClass class]);
HelloWorldClass *helloWorldObject = [[HelloWorld alloc] init];
[helloWorldObject mobileTest];
OCMVerify([mockObject makeNoise]);
}
There's not a simple answer to this without going a bit into what OCMock is meant for and what test design paradigm it implies.
The short version is: You should not test this like that in the first place. Tests should treat the tested methods as a black box and only compare & verify input vs output.
Longer version: You're trying to test for a side effect, basically, since makeNoise doesn't do anything that the HelloWorldClass even registers (or "sees"). Or to put it in a more positive way: As long as makeNoise is properly tested in the tests written for AnotherClass you don't need to test that simple call.
The example you provide may be a bit confusing, since obviously that doesn't leave anything meaningful to test in mobileTest's unit test, but considering that you might also question why to outsource the simple NSLog call to another class in the first place (and testing for an NSLog call is kind of pointless, of course). Of course I understand you're just using this as an example and envision a more complex different scenario in which you want to ensure that a specific call happens.
In such a situation, you should always ask yourself "Is this the correct place to verify this?" If the answer is "yes" that should imply that whatever message you want to test to be called needs to go to an object that's not completely inside the scope of the tested class only. For example, it could be a singleton (some global logging class) or a property of the class. Then you have a handle, an object that you can properly mock (for example, set the property to a partially mocked object) and verify.
In rare cases that might lead you to provide a handle/property for an object simply to be able to replace it with a mock during testing, but that often indicates a sub-optimal class and/or method design (I'm not gonna claim that's always the case, though).
Let me provide three examples from one of my projects to illustrate something similar to your situation:
Example 1: Verifying that an URL is opened (in mobile Safari): This is basically verifying that openURL: is called on the shared NSApplication instance, something very similar to what you have in mind. Note that the shared instance is not "completely inside the tested methods scope" as it is a singleton"
id mockApp = OCMPartialMock([UIApplication sharedApplication]);
OCMExpect([mockApp openURL:[OCMArg any]]);
// call the method to test that should call openURL:
OCMVerify([mockApp openURL:[OCMArg any]]);
Note that this works due to the specifics of a partial mock: Even though openURL: is not called on the mock, because the mock has a relationship to same instance that is used in the tested method it can still verify the call. If the instance weren't a singleton that would not work, you would not be able to create the mock from the same object that is used in your method.
Example 2: Adapted version of your code to allow "grabbing" the internal object.
#interface HelloWorldClass
#property (nonatomic, strong) AnotherClass *lazyLoadedClass;
#end
#implementation HelloWorldClass()
// ...
// overridden getter
-(AnotherClass *)lazyLoadedClass {
if (!_lazyLoadedClass) {
_lazyLoadedClass = [[AnotherClass alloc] init];
}
return _lazyLoadedClass;
}
-(void)mobileTest{
[self.lazyLoadedClass makeNoise];
}
#end
And now the test:
-(void)testMobileTest{
HelloWorldClass *helloWorldObject = [[HelloWorld alloc] init];
id mockObject = OCMPartialMock([helloWorldObject lazyLoadedClass]);
OCMExpect([mockObject makeNoise]);
[helloWorldObject mobileTest];
OCMVerify([mockObject makeNoise]);
}
The lazyLoadedClass method might even be in a class extension, i.e. "private". In that case, just copy the according category definition to the top of your test file (I usually do this, and yes, this is, IMO, a valid case of basically "testing private methods"). This approach makes sense if AnotherClass is more complex and requires elaborate setup or something. Usually stuff like this then leads to the scenario you have in the first place, i.e. its complexity makes it to more than just a helper than can be thrown away after the method finishes. this will then also lead you to better code structure, since you have its initializer in a separate method and can test that accordingly, too.
Example 3: If AnotherClass has a non-standard initializer (like a singleton, or it comes from a factory class) you can stub that and return a mocked object (this is kind of a brain-knot, but I have used it)
#implementation AnotherClass()
// ...
-(AnotherClass *)crazyInitializer { // this is in addition to the normal one...
return [[AnotherClass alloc] init];
}
#end
-(void)testMobileTest{
HelloWorldClass *helloWorldObject = [[HelloWorld alloc] init];
id mockForStubbingClassMethod = OCMClassMock([AnotherClass class]);
AnotherClass *baseForPartialMock = [[AnotherClass alloc] init];
// maybe do something with it for test settup
id mockObject = OCMPartialMock(baseForPartialMock);
OCMStub([mockForStubbingClassMethod crazyInitializer]).andReturn(mockObject);
OCMExpect([mockObject makeNoise]);
[helloWorldObject mobileTest];
OCMVerify([mockObject makeNoise]);
}
This looks kind of stupid and I admit it's plain ugly, but I have used this in some tests (you know that point in a project...). Here I tried to make it easier to read and used two mocks, one to stub the class method (i.e. the initializer) and one that then is returned. The mobileTest method should then obviously use the custom initializer of AnotherClass, then it gets the mocked object (like a cuckoo's egg...). This is useful if you want to specially prepare the object (which is why I used a partial mock here). I am actually not sure atm if you could also do this with only one class mock (stub the class method/initializer on it so it returns itself, then expect the method call you want to verify)... as I said, brain-knotting.
I may not completely understand mocking as I have a burning question about a very basic scenario. How does one test an instance method of a class OR how does one test a category method for a class?
Consider a class PeerMessage which defines a few properties, etc. I create my own custom category for PeerMessage called Type where I define a method, isTextMessage:. isTextMessage returns a boolean value based on the contents of a PeerMessage. (Please not that this is just an sample type.)
In a test with OCMock, I configure a mock of type PeerMessage and set it's content to some valid value as follows:
id peerMessage = [OCMockObject mockForClass:[PeerMessage class]];
[[[peerMessage stub] andReturn:#"<valid>"] content];
And then assert that peerMessage is a text message:
XCTAssert([peerMessage isTextMessage]);
Considering how mocking works, this results in: 'Unexpected method invoked'. Clearly, as I didn't specify that I was expecting it; neither did I stub it. As I just wanted to verify this API.
How does one test these instance methods (in this case, category instance methods). One way to do this is to redesign the category as follows:
Instead of
- (BOOL)isTextMessage;
do:
+ (BOOL)isTextMessage:(PeerMessage *)message;
But this is to me is very unnatural and I don't feel like writing this code although I don't see anything wrong with it. It doesn't need to be class method. :/
(If my explanation for the question is a bit ambiguous, I'd be happy to update.)
You want to use a partial mock, somehow like this:
id peerMessage = [OCMockObject partialMockForObject:[[PeerMessage alloc] init]];
[[[peerMessage stub] andReturn:#"<valid>"] content];
XCTAssert([peerMessage isTextMessage]);
This way, the real implementation of isTextMessage, the one you want to test, is invoked, but you can still stub out other methods on the object.
I would like to test if my init* method calls some other method within its body with OCMockito. Is this possible and if, how can I do it? Let's say, that I want to check if [self myMethod] has been called.
I've been trying to do it in a such naive way, but as you can imagine, with no success:
it(#"should trigger myMethod", ^{
DetailsView *mockDetailsView = mock([DetailsView class]);
[mockDetailsView initWithFrame:CGRectZero];
[verify(mockDetailsView) myMethod];
});
There are three possibilities depending of myMethod functionality.
Move myMethod call out from init
If myMethod realises very concrete logic of the object it should probably be called explicitly by the object's owner. Object creation shouldn't do anything more than setting its initial state. Then, if it's not in init it's easy to test.
Check object's state
If 'myMethod` configures object in some way, you can test its properties or its state rather than check if the method was called, because it's secondary - the final result is important.
Test the method...
Finally, if you really need to test whether myMethod was called, and none of above applies (which shouldn't happen), you can set in the method body a property self.myMethodCalled = YES.
This is super ugly, so you can derive from your class, override myMethod and set the property there, and then verify this call testing the subclass (which is unsafe and impure).
This is really hacky and indicates that probably something's wrong from the object design perspective.
I am going through an application and adding Unit Tests. The application is written using storyboards and supports iOS 6.1 and above.
I have been able to test all the usual return methods with no problem. However I am currently stumped with a certain test I want to perform:
Essentially I have a method, lets call it doLogin:
- (IBAction)doLogin:(UIButton *)sender {
// Some logic here
if ( //certain criteria to meet) {
variable = x; // important variable set here
[self performSegueWithIdentifier:#"memorableWord" sender:sender];
} else {
// handler error here
}
So I want to test that either the segue is called and that the variable is set, or that the MemorableWord view controller is loaded and the variables in there are correct. The variable set here in the doLogin method is passed through to the memorableWord segues' destination view controller in the prepareForSegue method.
I have OCMock set up and working, and I am also using XCTest as my unit testing framework. Has anyone been able to product a unit test to cover such a situation??
It seems that Google and SO are pretty bare in regards to information around this area.. lots of examples on simple basic tests that are pretty irrelevant to the more complex reality of iOS testing.
You're on the right track, your test wants to check that:
When the login button is tapped doLogin is called with the loginButton as the sender
If some criteria is YES, call performSegue
So you should actually trigger the full flow from login button down to performSegue:
- (void)testLogin {
LoginViewController *loginViewController = ...;
id loginMock = [OCMockObject partialMockForObject:loginViewController];
//here the expect call has the advantage of swallowing performSegueWithIdentifier, you can use forwardToRealObject to get it to go all the way through if necessary
[[loginMock expect] performSegueWithIdentifier:#"memorableWord" sender:loginViewController.loginButton];
//you also expect this action to be called
[[loginMock expect] doLogin:loginViewController.loginButton];
//mocking out the criteria to get through the if statement can happen on the partial mock as well
BOOL doSegue = YES;
[[[loginMock expect] andReturnValue:OCMOCK_VALUE(doSegue)] criteria];
[loginViewController.loginButton sendActionsForControlEvents:UIControlEventTouchUpInside];
[loginMock verify]; [loginMock stopMocking];
}
You'll need to implement a property for "criteria" so that there is a getter you can mock using 'expect'.
Its important to realize that 'expect' will only mock out 1 call to the getter, subsequent calls will fail with "Unexpected method invoked...". You can use 'stub' to mock it out for all calls but this means it will always return the same value.
IMHO this seems to be a testing scenario which has not properly been setup.
With unit tests you should only test units (e.g. single methods) of your application. Those units should be independent from all other parts of your application. This will guarantee you that a single function is properly tested without any side effects.
BTW: OCMock is great tool to "mock out" all parts you do not want to test and therefore create side effects.
In general your test seems to be more like an integration test
IT is the phase of software testing, in which individual software modules are combined and tested as a group.
So what would I do in your case:
I would either define an integration test, where I would properly test all parts of my view and therefore indirectly test my view controllers. Have a look at a good testing framework for this kind of scenario - KIF
Or I would perform single unit tests on the methods 'doLogin' as well as the method for calculating the criteria within your if statement. All dependencies should be mocked out which means within your doLogin test, you should even mock the criteria method...
So the only way I can see for me to unit test this is using partial mocks:
- (void)testExample
{
id loginMock = [OCMockObject partialMockForObject:self.controller];
[[loginMock expect] performSegueWithIdentifier:#"memorableWord" sender:[OCMArg any]];
[loginMock performSelectorOnMainThread:#selector(loginButton:) withObject:self.controller.loginButton waitUntilDone:YES];
[loginMock verify];
}
Of course this is only an example of the test and isn't actually the test I am performing, but hopefully demonstrates the way in which I am having to test this method in my view controller. As you can see, if the performSegueWithIdentifier is not called, the verify with cause the test to fail.
Give OCMock a read, I have just bought a book from amazon about Unit Testing iOS and its really good to read. Looking to get a TDD book too.
I am using OCHamcrest and OCMockito for unit testing an iOS project. I'm working my way toward understanding using custom matchers in a mock verification of a method expectation that takes parameters. In particular, I want to verify one of the parameters passed to the expected method, but I need to pull apart the passed parameter in order to do so. To demonstrate, here's what I have for the relevant part of my test method:
EAAccessory *accessory = mock([EAAccessory class]);
UIViewController <ZKSearchManagerDelegate> *mockController =
mockObjectAndProtocol(
[UIViewController class], #protocol(ZKSearchManagerDelegate)
);
[verify(mockController)
zkZSensorFound:isSensorWithAccessory(accessory)
fromSearchManager:_sm];
The -zkZSensorFound:fromSearchManager: takes an object that contains an EAAccessory as a property. In my custom matcher, I need to open up that object and examine that property to make sure it's the same object as accessory within this test method. It's easy enough to pass accessory into the matcher as I'm doing here, but how do I get at the actual object that is passed to the parameter for use inside of my matcher? Or, am I going about this all wrong?
Update
I've accepted the answer from #JonReid, as it's a much more elegant solution than what I've concocted. Nevertheless, I think what I was using (thanks to this blog post), could be useful elsewhere:
#import "ArgumentCaptor.h"
EAAccessory *accessory = mock([EAAccessory class]);
UIViewController <ZKSearchManagerDelegate> *mockController =
mockObjectAndProtocol(
[UIViewController class], #protocol(ZKSearchManagerDelegate)
);
ArgumentCaptor *captor = argCaptor();
[verify(_mockController) zkZSensorFound:(ZKZSensor *)captor
fromSearchManager:is(sameInstance(_sm))];
ZKZSensor *sensor = captor.argument;
assertThat(sensor.accessory, is(_mockAccessory));
First, be aware that when you don't specify a matcher to OCMockito, it uses the isEqual matcher. This probably isn't what you want to verify for the second argument. I'd check for identity instead:
fromSearchManager:sameInstance(_sm)
If the argument is typed, it will complain that the matcher sameInstance isn't a search manager. The workaround is to cast the matcher to remove the typing:
fromSearchManager:(id)sameInstance(_sm)
Now for the first argument: you may not need to make a custom matcher at all. If all you want to do is check a property value, use hasProperty. Assuming the property is named accessory,
zkZSensorFound:(id)hasProperty(#"accessory", sameInstance(accessory))
Putting it all together:
[verify(mockController)
zkZSensorFound:(id)hasProperty(#"accessory", sameInstance(accessory))
fromSearchManager:(id)sameInstance(_sm)];