v4.x
Getting Started
In-Depth
Mocking
Continuous Integration
Some Examples
The Collaborator
The premise of a collaborator is that it is an object that collaborates with another object for some purpose. Usually this is a dependency of some sort. Now, you can have a collaborator that is injected into the target object by some form of dependency injection, or it is created by the target object. Either way, you need to be able to mock the behavior of this collaborator object. The latter approach is much harder to test because you are doing a createObject() call. However, you need to put into practice your testable and refactor skills to work, in order to make this more testable. Thanks Marc Esher!
Example:
1
//hard to mock in a method call
2
function checkEmail(email){
3
var validator = createObject("component","model.util.Validator");
4
​
5
return validator.isEmail(arguments.email);
6
}
Copied!
The source above is too hard to test because you have no control over the create object call. Therefore you can have two solutions for this, which actually makes your code more testable.
- 1.Have a method return to you an instance of the Validator object.
- 2.Have the Validator object be injected via dependency injection into your target object.
Most of the time collaborators can be injected by dependency injection, but sometimes they will not as they are only in use by the target object. So let's do both approaches, starting with dependency injection via annotations: cfproperty.
1
<cfproperty name="Validator" type="model" instance="scope" />
2
​
3
//or setter injection
4
​
5
<cffunction name="setValidator" access="public" returntype="void" output="false">
6
<cfargument name="validator" type="any">
7
<cfset instance.validator = arguments.validator>
8
</cffunction>
Copied!
Now that we have a annotation injection or a setter injection, let's mock the collaborator into our target object with the mocked method for isValid email.
1
targetObject = createObject("component","model.TargetObject");
2
//prepare it for mocking, don't remove any methods
3
prepareMock(targetObject);
4
​
5
//Create our mock collaborator
6
mockValidator = getMockBox().createEmptyMock('model.Validator');
7
//Mock the isEmail valid method
8
mockValidator.$("isEmail",true);
9
​
10
//Inject it with setter injection
11
targetObject.setValidator(mockValidator);
12
​
13
//Inject it via mock property
14
targetObject.$property("validator","instance",mockValidator);
Copied!
There you go. Now let's refactor our method call:
1
function checkEmail(email){
2
return instance.validator.isEmail(arguments.email);
3
}
4
//or
5
function checkEmail(email){
6
return getValidator().isEmail(arguments.email);
7
}
Copied!
As you can see, even our method look cleaner and sharper thanks to our refactoring. However, the most important aspect of our refactoring is that now we can mock the collaborator.
Method Spies
The premise of method spies is that you want to mock the return of method calls inside the target object that we are testing because these methods are helper methods. Also, maybe these helper methods have an access type of private which we cannot mock directly. Here is a typical example in one of my security objects:
1
function userValidator(rule){
2
//validate a user
3
var user = getUserSession();
4
​
5
if( user.isAuthorized() ){
6
return true;
7
}
8
​
9
//Check if single sign on cookie exists and is valid
10
if( isSSOCookieValid() ){
11
authorizeUser(user);
12
}
13
else{
14
return false;
15
}
16
}
Copied!
Ok, this simple liner security validator throws tons of problems. Why? Well, I have three internal private calls:
- getUserSession() - supposed to return a nice user object
- isSSOCookieValid() - checks if a single sign on cookie is set
- authorizeUser() - Authorize a user in my system
Since I am unit testing this target object's
userValidator method, I don't really care about the method calls, I just worry about the behavior that is associated with them because my other tests will go into detail about what they do. However, for my purposes of testing the userValidator method, I just need behavior. Thus, we need to be able to create mocking representations of these methods.1
function beforeAll(){
2
//target object
3
security = prepareMock( createObject("component","model.Security") );
4
//create a mock user object
5
mockUser = createEmptyMock("model.User");
6
}
7
​
8
function run(){
9
​
10
describe( "A user", function(){
11
it( "can be authenticated", function(){
12
//mock user authorizations according to case calls
13
mockUser.$("isAuthorized").$results(true,false,false);
14
security.$("getUserSession", mockUser);
15
​
16
//case 1: authorized user
17
expect(security.userValidator()).toBeTrue();
18
​
19
//case 2: unauthorized user with invalid cookie
20
security.$("isSSOCookieValid",false);
21
expect( security.userValidator() ).toBeFalse();
22
​
23
//case 3: unauthorized user with valid cookie
24
security.$("isSSOCookieValid",true);
25
//mock the authorizeUser void call
26
security.$("authorizeUser");
27
expect( security.userValidator() ).toBeTrue();
28
});
29
});
30
​
31
}
Copied!
As you can see from the example above, I mocked all the necessary data and objects to test all the paths that I could follow in my
userValidator method. Now we are cooking with MockBox.Last modified 4yr ago
Copy link
Edit on GitHub