Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>When we are unit testing a class we are concerned with <em>'does the class do what we want it to do'</em>. Our starting point is a fully constructed instance; how we got there is not a unit testing question though it may be considered an integration testing question.</p> <p>Say we have,</p> <pre><code>A A(IB b, IC c) B : IB B(ID d) C : IC D : ID </code></pre> <p>When unit testing A, the fact that B uses ID should be moot (if it is not then we should look at our interfaces. Having A access IB.D.xxx is not good), all we need to do is provide A with some implementation (mocked/stubbed) of IB and IC.</p> <p>As far as the unit tests for A are concerned, whether the A instance is created by hand or by a container is not important. We get the same object either way.</p> <p>As long as we are passing in mocks as the first level dependencies then there is no saving when using a container over creating the object by hand. The saving only happens when we are creating object graphs using the IOC, but if we are doing this then we are into integration testing. This is not neccessarily a bad thing but we need to be clear on our goals.</p> <p>When unit testing the above we create unit testing for</p> <p>D C B (passing in a mocked/stubbed ID) A (passing in mocked/stubbed IC and IB)</p> <p>When unit testing A we do not need the correct answer from D to be passed through B up to A. <br /> All we care is that the logic in A works as expected, say, <em>A calls IB.x() with the parameters <strong>y</strong> and <strong>z</strong> and returns the result of IB.x()</em>. If we are checking that we get the <em>correct</em> answer (say, one which depends on logic in D) then we are past unit testing and into integration testing.</p> <p><strong>Bottom Line</strong> <br /> It does not matter whether or not the unit under test was created by an IOC container or by hand <em>as long as we are properly isolating the unit under test</em>. If we are using the container to create an object graph then the odds are good that we are into integration testing (and/or have problems with too much coupling between classes - A calling IB.D.xxx)</p> <p><strong>Mocking for Integration Tests</strong></p> <p>Caveat: Some of this following is dependent upon the IOC container in use. When using Unity, the last registration 'wins'. I do not know that this holds true for others.</p> <p>In the minimalist system under question we have </p> <p>A A (IB b)</p> <p>B : IB</p> <p>B is our 'leaf'. It talks to the outside world (say, reads from a network stream). When Integration testing, we want to mock this.</p> <p>For the live system, we set up the ServiceLocator using CreateContainerCore(). This includes the registration of the 'live' implementation of IB.</p> <p>When executing integration tests that require a mocked version of IB we set up the container using CreateContainerWithMockedExternalDependencies() which wraps CreateContainerCore() and registering a mocked object for IB. <br /></p> <p>The code below is heavily simplified but the shape extends out to as many classes and dependencies as required. In practice, we have a base test class that aids setting up the service locator, mocking/stubbing classes, accessing the mocks for verification purposes and other house keeping (e.g.so that each test doesn't need to explicitly set the ServiceLocator provider)</p> <pre><code>[TestClass] public class IocIntegrationSetupFixture { [TestMethod] public void MockedB() { ServiceLocator.SetLocatorProvider(() =&gt; new UnityServiceLocator(CreateContainerWithMockedExternalDependencies())); var a = ServiceLocator.Current.GetInstance&lt;A&gt;(); Assert.AreEqual("Mocked B", a.GetMessage()); } [TestMethod] public void LiveB() { ServiceLocator.SetLocatorProvider(() =&gt; new UnityServiceLocator(CreateContainerCore())); var a = ServiceLocator.Current.GetInstance&lt;A&gt;(); Assert.AreEqual("Live B", a.GetMessage()); } private IUnityContainer CreateContainerCore() { var container = new UnityContainer(); container.RegisterType&lt;IB, B&gt;(new ContainerControlledLifetimeManager()); return container; } private IUnityContainer CreateContainerWithMockedExternalDependencies() { var container = CreateContainerCore(); var mockedB = new Mock&lt;IB&gt;(); mockedB.SetupGet(mk =&gt; mk.Message).Returns("Mocked B"); container.RegisterInstance&lt;IB&gt;(mockedB.Object); return container; } public class A { private IB _b; public A(IB b) { _b = b; } public string GetMessage() { return _b.Message; } } public interface IB { string Message { get; } } private class B : IB { public string Message { get { return "Live B"; } } } } </code></pre>
    singulars
    1. This table or related slice is empty.
    1. POCan I use an IoC container in unit/integration tests?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USAlanT
    1. USAlanT
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POCan I use an IoC container in unit/integration tests?
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COI found an article that said that when doing integration testing one *should* use the app's IoC container so that the integration of parts that one is testing is the same as that used by the live app.
      singulars
      1. PO
      1. USIan Warburton
    2. CO@Ian Warburton Yep, for integration tests I agree. I got heavily focussed on unit testing in the answer. It can happen that we have nice integration tests which pass with flying colours but the actual app fails because the live IOC has not been wired up correctly. A common container setup which is used for both tests and production is good as long as one can swap out the leaf objects when integration testing - e.g replace a network service with a network serviec mock/stub
      singulars
      1. PO
      1. USAlanT
    3. COHow would you do that? Inherit from the container set-up class and override methods that add the leaf objects?
      singulars
      1. PO
      1. USIan Warburton
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

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