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.
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 added a set of classes to an array, all which I know have the same superclass:
[array addObject:[Africa class]];
[array addObject:[Brazil class]];
[array addObject:[France class]];
Later, I want to get the class object and call a superclass class method on it. Something like this:
Class class = [array objectAtIndex:1];
(Country class) specificClass = class;
I've tried a variation of different ideas, but can't figure out how to put that last line in code.
If I get you right you want a variable pointing to a class object, statically typed to a concrete class.
This not possible in Objective-C; there are no strongly typed class pointers. Class class is the best you can do.
You can send any known class method to a Class typed variable...
[class alloc];
[class defaultManager];
[class myCommonClassMethod];
... without making the compiler complain. Of course some of the examples might fail at runtime.
With a proper design pattern, you shouldn't need to know which country you are working with.
Start by creating an AbstractCountry class that declares (and provides stub implementations) of all the methods your countries need to generically respond to (i.e. countries can be more specific).
Then subclass that AbstractCountry for each individual country.
Then:
AbstractCountry *countryClass = [array objectAtIndex:n];
If you need behavior that only exists on a single country, then either push a stub implementation up (which wouldn't be terribly elegant) or test for response to selector (also not elegant) or cast appropriately (fragile).
Of course, all of this begs the question of why you have classes for this and not instances (though the instance design would be the same; consider something like UIControl and all the subclasses -- the control provides the abstract behavior of controls whereas the subclasses implement specific kinds of controls by oft overriding the abstract methods).
Usually in Objective-C you would call a method like so:
[class someMethod];
So in your case, let's pretend that your superclass (I'm assuming "Country") has a method to set the population or something, it would look like:
[Africa setPopulation:someInteger];
I'm finally imposing some TDD on a project I'm working on, and running into the edges... I know the code I want but not how to test for it :)
The implementation I'm looking for is:
- (void) doSomething
{
FooBuilder *foo = [[FooBuilder alloc] init];
[foo doSomethingElseWithCompletionBlock:^{
[self somethingDone];
}];
}
So I want my test to verify that a) the method under test allocates a new FooBuilder and b) that method then calls a method on the new object.
How do I go about this? I started down the path of trying to mock the alloc class method but quickly determined that down that path lies madness.
Note I'm not testing FooBuilder itself with this test, just that the collaboration is there.
Normally, dependency injection is used to provide a fully-formed object, saying "instead of asking for this object, here you go, use this." But in this case, we want the ability to instantiate a new object. So instead of injecting an object, all we have to do is inject the class. "Instead of creating a specific class, here you go, instantiate one of these."
There are two main forms of dependency injection: "constructor injection" (I'll stick with the term "constructor" even though Objective-C separates this into allocation and initialization) and "property injection".
For constructor injection, specify the class in the initializer:
- (instancetype)initWithFooBuilderClass:(Class)fooBuilderClass;
For property injection, specify the class in a property:
#property (nonatomic, strong) Class fooBuilderClass;
Constructor injection is clearer, because it makes the dependency obvious. But you may prefer property injection. Sometimes I start one way and refactor toward the other, changing my mind.
Either way, you can have a default initializer that either calls -initWithFooBuilderClass: , or sets the property, to [FooBuilderClass class].
Then doSomething would start like this:
- (void)doSomething
{
id foo = [[self.fooBuilderClass alloc] init];
...
I ended up addressing this by adding a new class method to FooBuilder which takes a completion block as an argument. So I've effectively moved the instantiation and method call out of my object-under-test into the collaborator object. Now I can mock that single class method call.
I think this ends up being slightly better design than what I started with; the detail that there needs to be a new FooBuilder instantiated is hidden from users of the class now. It's also pretty simple.
It does have the property that it maintains the strong coupling between my object-under-test and the FooBuilder class. Maybe that'll bite me down the road - but I'm making the YAGNI bet that it won't.
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)];
I'd like to test some code with OCMock.
The innards of the code are calling [NSObject isKindOfClass] on the mock object I'm providing to the code, like so:
if ([object isKindOfClass:[FancyClass class]]) { ...}
However, when I provide an OCMockObject-based mock created like this:
mock = [OCMockObject mockForClass:[FancyClass class]];
it appears that it does not pass the isKindOfClass test.
Any suggestions?
The general rule is that if you're calling isKindOfClass: and you're not passing one of the plist classes (e.g., NSString or NSNumber), You're Doing It Wrong.
If the method does two or more different things depending on which class its argument is, rend it into multiple methods, and test each method separately.
If the method does only one thing, but has to interact with the object differently depending on which class it is, then:
Make a protocol. (Protocols in Obj-C are called “interfaces” in some other OO languages, such as Java.)
Make the many classes all conform to the protocol. If necessary, use categories to add the necessary methods from outside.
Make the method under test check for conformance to the protocol, in place of the current isKindOfClass: check.
Make the method under test use the methods in the protocol.
What about:
[[[mock stub] andReturnValue:OCMOCK_VALUE((BOOL) {YES})] isKindOfClass:[FancyClass class]];