0

This is probably a damn fool question, for which I apologise, but I can't seem to get the google syntax right to find an answer.

Imagine a Property, like this:

private int _type
public int Type
{
    get { return _type; }
    set 
    {
        _type = value;
        //raise an event in your chosen language or tech
        CallAFunction();
    }
}

Now, imagine that CallAFunction does some sort of fairly serious heavy lifting in your application, interacting with the database via a repository.

It doesn't seem unreasonable to want a unit test for this, to make absolutely sure that Type gets set to whatever you put in and to check that doing so raises the expected event.

However, setting the property with a test will call CallAFunction() which means that you're no longer really testing a "unit" of code as such, and perhaps more importantly that a very simple test for this very simple property might well require more elaborate preparation, including repository mocking, which seems huge overkill.

In some cases you could split these apart by having CallAFunction raised via the event. But that's not always the case (I'm using WPF, and the events bubble up to non-testable XAML).

What's the best way to split these two interdependent things apart?

  • The usual way is to provide a fake CallAFunction() so that the test controls its behaviour and doesn't involve the real environment. – mouviciel May 8 '14 at 8:53
4

There are two issues intermingled here.

  1. "Is it OK to have hidden logic in a setter?" This is asked from time to time, and there is no accepted universal answer. It depends on whether the additional thing you do is really an intrinsic part of that property or not.
  2. "How do I test a method with an expensive external dependency?" Here the general opinion is that if your method does stuff via a collaborator, you should either mock that collaborator out, or use it normally while making sure that this does not make your unit test unacceptably slow.
  • Nice linkage. OK, regarding point two, (and apologies for stupidity) - am I right in thinking that I can't mock out CallAFunction unless I put it in a different object? You can't mock functions in the same object you're testing, right? – Matt Thrower May 8 '14 at 8:58
  • 1
    Not the call itself, but if you are actually talking to a repository of some sort, then whatever CallAFunction() does will eventually cross class boundaries, and that is where mocking can strike. – Kilian Foth May 8 '14 at 9:02
  • That goes back to my original point - it seems a lot of overhead to test a property, and CallAFunciton already has its own tests. But I guess the answer you're implying is that there is no easy/best approach to this. – Matt Thrower May 8 '14 at 9:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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