这是集成测试还是单元测试？

Question

More than a practical case, this is a question I have when trying to get a detailed difference between Unit Tests and Integration Tests.

Lets say I have class Sum, which adds two integers:

class Sum{
  int x;
  int y;
  public int add(){
    return x + y;
  }
  ...getters and setters...
}

And I have another class that is in charge of validate the results, to confirm that the values are the expected. Just for the example, let's say we want to add only positive numbers:

class ValidateSum{
   Sum sum;
   public boolean validate(){
      if(sum.getX()>=0 and sum.getY()>=0){
          return true;
      }
      else{
          return false;
      }
   }
   ... getters and setters...
}

Probably it doesn't make a lot of sense to have ValidateSum, but lets just assume it for the sake of the example.

And now I want to write tests for ValidateSum. If I do this:

@Test
public void testValidateSum(){
    ValidateSum vs = new ValidateSum();
    Sum sum = new Sum();
    vs.setSum(sum);
    boolean result = vs.validate();

    assertTrue(result);
}

Is that an Unit Test or an Integration Test?

I know that the unit test only has to validate the functionality in ValidateSum, and in a way the test is doing it: It only gets properties from Sum, and not really any of its functionality.

But on the other side, you can also say that you do are accessing functionality from Sum, even if ValidateSum only calls a getter. Any change in Sum's getters would impact the tests for ValidateSum, breaking the concept of Unit Tests.

But if this is the case and indeed it is an Integration Test, then how can I write an Unit Test for ValudateMethod's validate() ?

The only thing I can't think of is mocking Sum, so it alwas returns the same value. And even if the logic inside Sum's getter changes, the test for ValidateSum would remain intact. The problem is that mocking responses of getters could be adding unnecessary complexity since the probability for changes to the logic inside a getter is very low, and all we are doing is getting a property.

I hope that my question makes sense, which is more of a theoretical doubt.

Edit

Thank you for your answers. They have important things to have in mind. The one I selected as the best answer was because it lead me to this:

http://www.mockobjects.com/2007/04/test-smell-everything-is-mocked.html

And its true: Theoretically I would have to mock Sum so it becomes a pure Unit Test. But for most of the cases, the cost of the complexity added and the effort spent in mocking properties getters are not worth just to get a "purest" unit test, when in practice for this case the difference between Unit and Integration test is subjective.

Answer 1

Don't mock Sum . Getters and setters in general don't have logic. Mocking is the process of removing a class's logic so that it doesn't interfere with another class's tests. Mocking a class without any logic, or a class whose logic is not involved with the current test is pointless. In fact, "don't mock value objects" is a well known principle of unit testing.

Your test is not using any of the logic of the Sum class. So it's a unit test.

Answer 2

But if this is the case and indeed it is an Integration Test, then how can I write an Unit Test for ValudateMethod's validate()?

Simply by

(...) mocking Sum, so it always returns the same value.

The line between integration and unit is often hard to draw. But let's try to do that, starting with:

Integration tests will test interactions between multiple components .

What is a component then? In most cases -- business entity, a class with some logic required to making your software run.

How does the Sum class fit in here? Does it contain business logic essential to make your software run? If so, having it not mocked would make your test integrating one (if we stick to the simple definition above).

However, Sum class could be just as well a class storing values, having little business logic -- a data structure , if you will. Business entities operate on data structures all the time: integers , strings , Points , Addresses -- all data structures, not requiring any integration to be done.

Classification is up to you and responsibilities you assign to your classes. Interacting with data structures doesn't need integration. Interacting with other business entities might.