My team is trying to find out the best way to test one of our components; the main scope is to check if the user/actor has the right to complete the operation requested. The component is formed by many functions that usually have the following structure (simplified):
Example language: PHP
public function addGroup($idEntity, $nameGroup){
if (!$this->logic->isEntityActive($idEntity)){
throw new EntityNotActiveException();
}
if ($idEntity != $this->getServiceLocator()->get('request')->getQuery()->get('idEntity')){
throw new NoRightsException();
}
if ($this->logic->isGroupWithNameAlreadyInDB($idEntity, $nameGroup)){
throw new GroupAlreadyExistException();
}
return $this->logic->addGroupToEntity($idEntity, $nameGroup);
}
As you can see this method has no “logic” per se (apart from the checks) and in the end it just forwards the request to the logic underneath. We are conflicted about how to correctly test this function. Do we mock everything? We can do it and in each test fake some “failures”, but the problem remains that to test the correctness of the function you mock everything. Every single function. In that case you are not testing anything. We could really use some advice on this problem. Can anybody show us examples of a good way to test a function like this?
We use phpunit. Thank in advance for your help.
0
My opinion is that you mock everything. You are making sure that the checks are acting correctly not the underlying logic in the function call that returns the true/false). Mocking this also removes understanding the logic behind the function calls in each of the conditions. And this test won’t fail if/when that logic changes which would become a maintenance nightmare.
The main problem with that is in this line:
if ($idEntity != $this->getServiceLocator()->get('request')->getQuery()->get('idEntity'))
As you end up with a mock return a mock. This is a code smell and violates the D in SOLID (http://en.wikipedia.org/wiki/Law_of_Demeter). I would consider refactoring this so that you pass in the result of getQuery().
I would probably end up writing seperate tests for the exceptions and one for the success. As the mocks for each would end up expecting different calls.
EDIT:
Keep in mind that the tests help provide insight into the expected behavior of the code, and also for making sure that any changes in the logic do not break existing functionality.
If you want to change the conditions of addGroup, you can make sure that you have maintained existing functionality without having to dig into the underlying function calls.
Here is what the exception test would look like (using PHPUnit):
/**
* @dataProvider dataExceptions
*/
public function testAddGroupExceptions($isActive, $inGroup, $id, $exception) {
$this->expectsException($exception);
$logic = $this->getMockBuilder('logic')->setMethods(array('isEntityActive', 'isAlreadyInGroup', 'addGroupToEntity'))->getMock();
//Set number of calls to any to not tie to order in function
$logic->expects($this->any())->method('isEntityActive')->will($this->returnValue($isActive));
$logic->expects($this->any())->method('isAlreadyInGroup')->will($this->returnValue($isActive));
//This is a fail case, so do not add group
$logic->expects($this->never())->method('addGrouptToEntity');
//Not doing all the mocks to get the 'idEntity'
$query = $this->getMockBuilder('query')->setMethods(array('get'))->getMock();
$query->expects($this->any())->method('get')->with('idEntity')->will($this->returnValue($id));
$idEntity = 'test';
$group = 'foo';
//Instantiate the object - $test
$test->addGroup($idEnity, $group);
}
3
There is no point unit testing something trivial. There has to some logic there for there to be any value to a unit test.
In this case it might be worth covering it indirectly with your wider spanning integration tests.
Don’t unit test trivial functions such as properties with no validation logic. Your integration testing should adequately cover such methods.