Unnecessary unit test?

Question

I have this method in my service layer

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

I've written a unit test like this

 [Fact]
 public void GetModulesTest()
 {
 //Arrange 
 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();
 //Act
 var actualResponse = userService.GetModules(request);
 //Assert
 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?

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.

• Null Reference: Ah I see, oh well, my organization has a fixation over 100% code coverage.
• Rudi: 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/…
• Raj: @the8thbit unfortunately that's no good. It might actually work against you. IN reality "sometimes" 20% coverage is better than 80% coverage.