I have this method in my service layer

    public ModuleResponse GetModules(ModuleRequest request)
        var response = new ModuleResponse(request.RequestId);
            response.Modules = Mapper.ToDataTransferObjects(ModuleDao.GetModules());
            return response;
        catch (Exception ex)
            response.Acknowledge = AcknowledgeType.Failure;
            response.Message = "An error occured.";
            return response;

I've written a unit test like this

    public void GetModulesTest()
        var mockModuleDao = Mock.Create<IModuleDao>();
        var mockLog = Mock.Create<ILog>();
        var mockAuditDao = Mock.Create<IAuditDao>();

        var moduleList = new List<ModuleItem>
            new ModuleItem {Id = 100, Category = "User Accounts", Feature = "Users"},
            new ModuleItem {Id = 101, Category = "User Accounts", Feature = "Roles Permissions"}

        mockModuleDao.Arrange(dao => dao.GetModules()).Returns(moduleList);

        IUserManagementService userService = new UserManagementService(mockModuleDao, mockLog, mockAuditDao);

        var request = new ModuleRequest().Prepare();

        var actualResponse = userService.GetModules(request);

        Assert.Equal(AcknowledgeType.Success, actualResponse.Acknowledge);
        Assert.Equal(2, actualResponse.Modules.Count);

My question is... are such methods worth testing? I have a whole other bunch of retrieve methods that just return me lists of data.

Are there any other ways to improve the unit test in this particular example?

The first assert basically checks if the method has been executed without any error.

Is the 2nd Assert of my test redundant?


1 Answer 1


In my opinion No. There is hardly any behaviour at all. As soon you say "I have this method in my service layer" it make it much more obvious. Service layer provide communication and pretty much should orchestrate things. That's it.

Note that Unit tests are good but have it unnecessary written they become a maintenance issue.

Test your code which has behaviour from the customer's requirements point of view.

Typically you would have an acceptance type test or an integration test to cover service layer and other layers as well.

  • \$\begingroup\$ Ah I see, oh well, my organization has a fixation over 100% code coverage. \$\endgroup\$ Commented Apr 9, 2014 at 13:28
  • 1
    \$\begingroup\$ As I tend to agree with 100% code coverage, for most teams, you might then be able to refactor the unit test to have a generic base test that covers all of those service layer calls. perhaps this can also help in refactoring the TryCatch logic codereview.stackexchange.com/questions/11999/… \$\endgroup\$
    – Rudi
    Commented Apr 9, 2014 at 14:42
  • \$\begingroup\$ @the8thbit unfortunately that's no good. It might actually work against you. IN reality "sometimes" 20% coverage is better than 80% coverage. \$\endgroup\$
    – Raj
    Commented Apr 9, 2014 at 23:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.