Home/ Questions/Q 8267791
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-08T05:39:38+00:00

I was writing a test, and I had to pass a mock into a

  • 0

I was writing a test, and I had to pass a mock into a particular method. I was wondering, is there any benefit of passing it via the constructor or directly into the method in question. Or does it not really matter.

For example

Passing interface/mock via the constructor

class User()
{
  IClock clock;

  User(IClock clock) {this.clock = clock;}

  User GetUser(){ ..}
  UpdateUser(User user) {
     ... 
     this.clock.Now();
     ...
  }
}

vs

Passing interface/mock into the method

class User()
{
  User GetUser(){ ..}
  UpdateUser(IClock clock, User user) {
     ... 
     clock.Now();
     ...
  }
}

Thanks!

EDIT

In this case, IClock will be wrapping DateTime. I do this for testability. So effectively, I will have an override that will construct the IClock within itself.

EG. For the method case:

UpdateUser(User user) {
  UpdateUser(new Clock(), user);
}

Clock will encapsulate DateTime.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    IClock in this case is a hidden singleton – it produces the current date-time from the underlying operating system. If you want to write reliable acceptance tests you will need to stub out the date-time provider in those tests.

    Because of this you will need to expose this dependency all the way up to the module boundary, and then inject a common date-time source into your module (and perhaps even the whole system). You will sometimes stub this “IClock” date time source when writing your acceptance tests.

    This will allow you to answer questions such as:

    • does my system work on a leap day?
    • does my system work at midnight?
    • does my system work on new-year’s eve?

    Having the IClock dependency in either the constructor signature or the method signature will clearly document to the user that your method or object is date-time dependent. Dependence on date-time is normally of critical importance when trying to understand the behaviour of an object so should be given prominence. Typically avoid anything that hides this dependency (such as supplying a default date-time source in an overloaded method definition) as this will prevent you from writing acceptance tests like those that I have described above.

    Choosing between passing a dependency into the constructor or the method will typically depend on the responsibilities of the method to the rest of the system. The methods form the public protocol that the object will use to communicate with its peers in the running system, whereas the constructor parameters are the dependencies that this particular implementation needs to perform its role.

    Ask yourself the questions:

    • Does the responsibility of this method necessarily entail knowledge of the date-time?
    • Or is it something to do with the particular implementation of the method in this particular object that means it needs the date-time?
    • Would it be reasonable for the caller of the method to be responsible for manipulating this object’s view of the date-time, or is that the responsibility of the module configuration?
    • If I swapped this object with another implementation of the same interface, would it be reasonable that that implementation did not need the date-time for this method?
    • How many methods in your object need the date-time? Do they need the same view of the date-time?
    • 0