views:

25

answers:

1

I'm hoping someone can help me see the real value in these tests because I read a lot about them and even worked with them on a recent project. But I never really saw the real value in the tests. Sure I can understand why they are written and see how they could sort of be useful. But it just seems that there is little ROI on these types of tests. Here is an example of some class in our code base:

class ServiceObject : IServiceObject
{
    Dependency _dependency;

    ServiceObject(Dependency dependency)
    {
        this._dependency = dependency
    }

    bool SomeMethod()
    {
        dependency.SomePublicMethod();
    }
}

Then in our behavioral tests we would write test like so (pseudo code):

void ServiceObject_SomeMethod_Uses_Dependency_SomePublicMethod()
{
    create mock of IServiceObject;
    stub out dependency object
    add expectation of call to dependency.SomePublicMethod for IServiceObject.SomeMethod

    call mockserviceobject.SomeMethod

    check whether expectation was satisfied
}

Obviously there are some details missing but if you are familiar with this type of testing you will understand.

So my question really derives from the fact that I can't see how it is valuable to know that my ServiceObject calls into the dependency method. I understand the reasoning behind it because you want to make sure that the logic of the method is hitting the parts that it is supposed to. But what I can't see is how this is a sustainable testing pattern?

I wrote the logic and know how the code should work so why would it ever change after I test it once to make sure that it is working? Now you can say that if you work in a team environment you might want to make sure that someone doesn't come along and change the code so that the dependency is accidentally skipped and thus would want to make sure they are aware of it. But what if it was skipped for a valid reason. Then that whole test and maybe any others would all have to be scrapped.

Anyways I am just hoping for someone to turn the light on as to the true potential of these types of tests.

A: 

The objective is to test the class in isolation, truly Unit test it. Verify that it performs exactly its responsibilities.

In this case the code is rather trivial. The value of this kind of testing may become more clear when there is conditionality in the processing path, parameters are passed to the dependency and processing is performed on the results from the dependency.

For example, suppose instead a method was like this:

bool someMethod(int paramX, int param Y ){

    if ( (paramX / paramY) > 5 ){
         return dependency.doOneThing(paramX);
    } else {
         return dependency.doSomethingElse(paramY);
    }

}

Now we have quite a few tests to write, and I think the value becomes more obvious. Especially when we write a test with paramY set to zero.

djna
Yeah I can see the point in that.
spinon