{"__v":3,"_id":"5447ef7a8d7af31a00dd4125","category":{"__v":1,"_id":"544854e74544c30800241f51","pages":["544853a8c1b42e08005b82b6","5447ecac8d7af31a00dd4119","5447ed6d0319802200fc0705","5447ef7a8d7af31a00dd4125","54485217c1b42e08005b82a6","5448536e4544c30800241f48","54485396c1b42e08005b82b2","547c7c5f78fd57080023c99c"],"project":"54471fc9e12a270800028adc","version":"54471fc9e12a270800028adf","sync":{"url":"","isSync":false},"reference":false,"createdAt":"2014-10-23T01:07:51.270Z","from_sync":false,"order":2,"slug":"basics","title":"Basics"},"is_link":false,"project":"54471fc9e12a270800028adc","user":"54471f91beb6320800da6f75","version":{"__v":10,"_id":"54471fc9e12a270800028adf","project":"54471fc9e12a270800028adc","createdAt":"2014-10-22T03:08:57.750Z","releaseDate":"2014-10-22T03:08:57.750Z","categories":["54471fc9e12a270800028ae0","5447b9e7b96a63140077d747","5447be130319802200fc0620","5447ed118d7af31a00dd411c","5447ed230319802200fc0702","5448524c4544c30800241f41","544854504544c30800241f4d","544854af4544c30800241f50","544854e74544c30800241f51","54485557c1b42e08005b82bf"],"is_deprecated":false,"is_hidden":false,"is_beta":false,"is_stable":true,"codename":"","version_clean":"1.0.0","version":"1.0"},"updates":[],"next":{"pages":[],"description":""},"createdAt":"2014-10-22T17:55:06.078Z","link_external":false,"link_url":"","githubsync":"","sync_unique":"","hidden":false,"api":{"basic_auth":false,"results":{"codes":[]},"try":true,"auth":"never","params":[],"url":""},"isReference":false,"order":4,"body":"SpecsFor includes an auto-mocking container.  What's that, you ask?  It's a special Inversion of Control container that resolves dependencies using mock objects.  \n\nAt test-time, when SpecsFor creates your [System Under Test (SUT)](doc:the-system-under-test-sut), it does so using its auto-mocking container.  Any dependencies that your SUT has are resolved (recursively) using the container.  If a dependency is mockable, meaning it is either an abstract type or or an interface type, the container will create a new mock object using the Moq framework, then it will inject that mock object for you automatically.  \n\nConceptually, you can think of the auto-mocking container as doing the following for you:\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"SUT = new YourTargetClass(new Mock<IService1>().Object, new Mock<IService2>().Object);\",\n      \"language\": \"csharp\"\n    }\n  ]\n}\n[/block]\nThis mocking occurs recursively, too.  If your class depends on a concrete type, the container will create an instance of the concrete type.  If that concrete type has a dependency on a mockable type though, it will inject mock objects for those dependencies.\n\nYou can retrieve any mock object that has been created by the auto-mocking container by calling the GetMockFor<T> method on the SpecsFor base class.  \n\nFor more information check out [how to set up a mock object](doc:set-up-a-mock-objection) and [how to verify a method was called](doc:verify-a-method-was-called-on-another-object).  You can also reconfigure the behavior of the auto-mocking container, such as [registering a concrete type](doc:register-a-concrete-type-in-the-auto-mocking-conta).","excerpt":"","slug":"about-auto-mocking","type":"basic","title":"About auto-mocking"}

About auto-mocking


SpecsFor includes an auto-mocking container. What's that, you ask? It's a special Inversion of Control container that resolves dependencies using mock objects. At test-time, when SpecsFor creates your [System Under Test (SUT)](doc:the-system-under-test-sut), it does so using its auto-mocking container. Any dependencies that your SUT has are resolved (recursively) using the container. If a dependency is mockable, meaning it is either an abstract type or or an interface type, the container will create a new mock object using the Moq framework, then it will inject that mock object for you automatically. Conceptually, you can think of the auto-mocking container as doing the following for you: [block:code] { "codes": [ { "code": "SUT = new YourTargetClass(new Mock<IService1>().Object, new Mock<IService2>().Object);", "language": "csharp" } ] } [/block] This mocking occurs recursively, too. If your class depends on a concrete type, the container will create an instance of the concrete type. If that concrete type has a dependency on a mockable type though, it will inject mock objects for those dependencies. You can retrieve any mock object that has been created by the auto-mocking container by calling the GetMockFor<T> method on the SpecsFor base class. For more information check out [how to set up a mock object](doc:set-up-a-mock-objection) and [how to verify a method was called](doc:verify-a-method-was-called-on-another-object). You can also reconfigure the behavior of the auto-mocking container, such as [registering a concrete type](doc:register-a-concrete-type-in-the-auto-mocking-conta).