正确的单元测试属性持有者，不等于实现

Question

I am having a debate with a colleague about a specific situation that I encountered, and would be great if someone could chime in with some view or theory grounding.

Let's say that we have model objects of type A. They are java beans, property holders, and have methods like getPrice, getQuantity, getName ..

Let's also assume that for some legacy reason, the equals method returns true, on two different objects, even if they have different property values!

I'll provide some code that exemplifies this problem. (Obviously not the same code, taken shortcuts)

 class A {
    private final double q;
    private final double p;

    public A(double q, double p) {
        this.q = q;
        this.p = p;
    }

    public double getQuantity()
    {
        return q;
    }
    public double getPrice()
    {
        return p;
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;

        // not the actual method but a.equals(aWithDifferentValues) is True
        // this is the crux of the problem 
        return true;
    }

}

public abstract class Handler {
    protected Manager m;

    public Handler(Manager m) {
        this.m = m;
    }

    abstract public void handle(A a);
}

class HandlerA extends Handler {

    public HandlerA(Manager m) {
        super(m);
    }

    @Override
    public void handle(A a) {
        m.f(a, "abc");
    }
}

...

class HandlerC extends Handler {

    public HandlerC(Manager m) {
        super(m);
    }

    @Override
    public void handle(A a) {
        m.g(a, 1);
    }
}

class Manager {
    public void f(A a, String s) { }
    public void g(A a, double q) { }
}

We want to unit test HandlerA.

So we might want to write a test like this:

public class TestMain {

    @Test
    public void givenA_fHappens() {

        Manager manager = mock(Manager.class);
        HandlerA handler = new HandlerA(manager);

        A givenA = new A(7, 9);

        handler.handle(givenA);
        verify(manager).f(givenA, "abc");
    }
}

The problem now arrises that because the equals returns true, for different A object with different properties making this modification in the code :

    @Override
    public void handle(A a) {
--        m.f(a, "abc");
++        m.f(new A(1, 1), "abc");
    }

will not be covered by the unit test

I suggested that we use a matcher with the verify, (or asserts where there are argument captors) in fact there already is one called SamePropertyValueAs that could serve, but I was met with criticism that we don't want to assert that they have the same values, only that the code is called.

What do you think? What are your opinions on this?

Answer 1

The answer really lies on what you are aiming to test. Based on this the answers would vary.

1. Are you testing that the instance passed is the same in the sense reported by equals method? If so, then verify(manager).f(givenA, "abc") is enough (provided you trust that object equality has been implemented for the given class). In most cases, this is desirable because it makes more sense semantically and we don't want to worry about low level details such as object reference equality. In your example above, ideally the equals method should be fixed :)

2. Are you testing that the same object reference is passed to the method? In some cases we might want to explicitly check that the object passed is indeed the same reference that was used internally and not substituted by a equivalent looking object. This is rather rare, but if there is such a need, use an ArgumentCaptor and assert the reference equality between the sent and captured value.

Coming to the point where you mentioned we don't want to assert that they have the same values, only that the code is called .

Personally I don't agree that it is enough to assert that the method was called. What if the value passed is different (like the one you mentioned). This would make the tests incomplete and make the code brittle. Such tests only make the coverage report look green but lack complete functional coverage.