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.
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.
3
> 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
MyComplicatedBusinessCalculationand - class
MyPermissionManagerand - webservice
MyComplicatedBusinessCalculationWebservicethat 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
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.
4