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 _typepublic 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?
Unit-based architecture
design;architecture;unit testing
There are two issues intermingled here.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.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.