Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>What we've decided to do is create a class, in your case it would be <code>LoggingConfiguration</code>, and have that passed to the constructo of the repository. If you resolve using Unity it will instantiate this class using <code>Activator</code>, wuthout having to register it. In your tests however, you just greate a new instance of a derived configuration class, providing different values. </p> <p>Does it makes sense? Should I clarify more?</p> <p><strong>Update</strong>: I've decided to provide some additional clarification. So, you already have two implementations, and now you want each configuration to query for its proper configuration setting. </p> <p>I would extend the <code>ILoggingRepository</code>'s constructor to look like this:</p> <pre><code> public ILoggingRepository(ILoggingConfigurationProvider confProvider); </code></pre> <p>You can then create one implementation for your normal operation which has two properties:</p> <pre><code>public LoggingConfigurationProvider : ILoggingConfigurationProvider { public LoggingConfigurationProvider() { // load both values from configuration file } public string LogPath { get; set; } public string ConnectionString { get; set; } } </code></pre> <p>When you instantiate your class via normal IoC operation this will get resolved by the container and you'll configuration options will get loaded from the conf file. When you however want to do Unit tests you:</p> <p>1) Create a new "Mock" implementation</p> <pre><code>public class MockLoggingConfigurationProvider : ILoggingConfigurationProvider { public MockLoggingConfigurationProvider() { // set both values to a test value } public string LogPath { get; set; } public string ConnectionString { get; set; } } </code></pre> <p>Now you can either create the repository using a constructor:</p> <pre><code>new LoggingRepository(new MockLoggingConfigurationProvider()); </code></pre> <p>or if you want the whole IoC mechanism to be used, you simply (when setting up the container) register this implementation of the interface. Because the unit tests are separate, you don't share the registrations right? So that should give you what you need, the ability to change this settings depending on weather they are being executed as a unit test or not.</p> <p>In real life, I wouldn't even bother with this, and just create a mock logging repository and have it write somewhere else. Unless you want to test the repository to a test database/file. In which case I'd do as specified.</p> <p>Hope it helps.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload