title: unit testing & constructor dependency injection
body: <p>I have an issue regarding how one would go about designing an application suited for unit-testing.</p>
  
  <p>I am trying to implement the SRP (Single-Responsibility Principle), and from what I understood this involves splitting out most functionality in seperate, dedicated classes to keep code more organised.  For example, I have this specific scenario.</p>
  
  <p>A class <code>RecurringProfile</code>, which has a method <code>.ActivateProfile()</code>.  What this method does is mark the status as activated, and create the next (first) recurring payment for the next due date.  I was going to split out the functionality to create the next recurring payment in a seperate class, for example <code>RecurringProfileNextPaymentCreator</code>.    My instant idea is to have this class take the <code>'RecurringProfile'</code> as a parameter in it's constructor:</p>
  
  <pre><code>RecurringProfileNextPaymentCreator(IRecurringProfile profile)
  </code></pre>
  
  <p>However, I think this would be problematic for unit-testing.   I would like to create a unit-test which tests out the <code>ActivateProfile</code> functionality.  This method would get an instance of an <code>IRecurringProfileNextPaymentCreator</code> via dependency injection (Ninject), and call the method <code>.CreateNextPayment</code>.</p>
  
  <p>My idea to create a unit-test was to create a mock of an <code>IRecurringProfileNextPaymentCreator</code>, and substitue that so that I can verify that the <code>.ActivateProfile()</code> actually called the method.  However, due to the constructor parameter, this would not fit as a default constructor for NInject.  Having to create a custom NInject provider just for such a case (where I can have many such classes all over the solution) would be a bit overkill.</p>
  
  <p>Any ideas / best practices how one would go about this?</p>
  
  <p>--
  Below is a sample code regarding the above example: (Please note that the code is hand-written, and is not syntactically 100% correct)</p>
  
  <pre><code>public class RecurringProfile
  {
      public void ActivateProfile()
      {
          this.Status = Enums.ProfileStatus.Activated;
          //now it should create the first recurring payment
          IRecurringProfileNextPaymentCreator creator = NInject.Get&lt;IRecurringProfileNextPaymentCreator&gt;();
          creator.CreateNextPayment(this); //this is what I'm having an issue about 
      }
  }
  </code></pre>
  
  <p>And a sample unit-test:</p>
  
  <pre><code>public void TestActivateProfile()
  {   
      var mockPaymentCreator = new Mock&lt;IRecurringProfileNextPaymentCreator&gt;();
      NInject.Bind&lt;IRecurringProfileNextPaymentCreator&gt;(mockPaymentCreator.Object);
  
      RecurringProfile profile = new RecurringProfile();
      profile.ActivateProfile();
      Assert.That(profile.Status == Enums.ProfileStatus.Activated);
      mockPayment.Verify(x =&gt; x.CreateNextPayment(), Times.Once());
  
  }
  </code></pre>
  
  <p>Going up to the sample code, my issue is whether it is a good practice to pass over the RecurringProfile as a parameter to the <code>creator.CreateNextPayment()</code> method, or whether it makes more sense to somehow pass the <code>RecurringProfile</code> to the DI-framework, when getting an instance of an <code>IRecurringProfileNextPaymentCreator</code>, considering that the <code>IRecurringProfileNextPaymentCreator</code> will always act on an <code>IRecurringProfile</code> to create the next payment. Hope this makes the question a bit more clear.</p>