Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Suppose that I have a class that implements some logic:

public MyLogicImpl implements MyLogic {
    public void myLogicMethod() {
        //my logic here
    }
}

and somewhere else a test class:

public MyLogicImplTest {
    @Test
    public void testMyLogicMethod() {
        /test my logic
    }
}

I also have:

@WebService
public MyWebServices class {
    @Inject
    private MyLogic myLogic;

    @WebMethod
    public void myLogicWebMethod() {
        myLogic.myLogicMethod();
    }
}

Should there be a test unit for myLogicWebMethod or should the testing for it be handled in integration testing.

share|improve this question
add comment

3 Answers

up vote 4 down vote accepted

Consider the different pressures involved. 100% Code coverage in your unit tests is a valid goal, since it protects you from regressions happening through casual changes, through requirements changes, environment changes, etc. On the other hand, writing regression tests in itself consumes valuable time. If you have completely regular or even automatically generated accessors or wrappers, those are probably the least likely to introduce subtle errors through later changes, so writing tests against these should be the lowest priority. In practice, you often don't have enough time to achieve 100% code coverage (let alone 100% state coverage), but the very act of thinking about your system and deciding which parts to test preferably is already much, much better than not having regression tests.

So my answer would be: you should, but if that is not feasible in your work environment, it's not as bad as lacking unit tests against more complicated parts of the code base.

share|improve this answer
    
So if the 100% test coverage isn't a project goal then testing these type of methods is not mandatory? I do not see any reason for testing them at all, as unit tests, since they do not do anything. –  m3th0dman Nov 19 '12 at 7:44
1  
They don't now, but regression tests are almost entirely about the future. They establish a base line of behaviour of the entire system that you can know you will be able to rely on not changing. Someone might get a bright idea and add logic to the wrappers to fix this or improve that. A unit test makes sure that this doesn't break anything in the process. –  Kilian Foth Nov 19 '12 at 8:18
    
If someone wants to add/change logic of a wrapper method the supporting test needs to be changed; if it is not existent it can be created. –  m3th0dman Nov 20 '12 at 10:35
add comment

Your web service method almost certainly produces different output than your bare method. It may be a massive SOAP envelope wrapped around your simple "Hello, World!" response. It may be a RESTful HTTP response. But it is almost certainly different. So yeah, test it differently.

share|improve this answer
    
Shouldn't that mean that I test JAX-WS/-RS implementation? It's their job to put my response in an envelope well... Anyhow, this is just an example; think about other wrappers, that do not change the output. –  m3th0dman Nov 20 '12 at 6:56
    
Sure, it's "their" job. But it's a complex process, and even simple processes break sometimes. If you trust the code, don't test it. But then ask yourself why you test any code at all. –  Ross Patterson Nov 20 '12 at 11:51
    
A wrapper that doesn't change the output still has a purpose, and that purpose ought to be tested. At work, I have a wrapper that logs information about the thing it wraps. A proper test for that would look at the log stream and confirm that the correct information was logged. –  Ross Patterson Nov 20 '12 at 11:54
    
1stComment: IMHO, you should test your code not others'. –  m3th0dman Nov 20 '12 at 12:00
add comment
 > Should adapters or wrappers be unit tested

yes the main responsibility of the wrapper should be unit tested through the wrapper

no not the complete functionality should be unit tested through the wrapper

Here is an example that illustrates what i mean:

if you have a

  • class MyComplicatedBusinessCalculation and
  • class MyPermissionManager and
  • webservice MyComplicatedBusinessCalculationWebservice that combines calculation and permissions

you should have full unittests for calculation and full unittests for permissions.

For the webservice you should only have to test that for every webservice method the corresponding calculation is called and that permissioncheck is applied.

There is no need to test through webservice the combinations of permissions are correct since you already have tested these with the permission-unittests.

There is no need to test through webservice the different edgecases for businesscalculations since you already have tested these with the calculation-unittests.

I would not recomment to test the underlying classes through the webservice.

Example:

If MyPermissionManager changes only the MyPermissionManager-Unittests must be updated but not the webservice-tests

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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