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: PHPpublic 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.
Unit-testing functions without business logic (only checks)
php;unit testing;zend framework;mocking;phpunit
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);}