{"__v":4,"_id":"5447ed6d0319802200fc0705","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":["5527914acd9bde1700983c51"],"next":{"pages":[],"description":""},"createdAt":"2014-10-22T17:46:21.023Z","link_external":false,"link_url":"","githubsync":"","sync_unique":"","hidden":false,"api":{"basic_auth":false,"results":{"codes":[]},"settings":"","try":true,"auth":"never","params":[],"url":""},"isReference":false,"order":3,"body":"Your spec goes through several different phases as it executes.  Many of these phases can be overridden.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Extension Points\"\n}\n[/block]\nWhile just about every step of the SpecsFor lifecycle can be overridden, you typically will only override one of the following points:\n\n* ConfigureContainer - You can override this method to change the configuration of the auto-mocking container.  You can [register a concrete type](doc:register-a-concrete-type-in-the-auto-mocking-conta), load registries, etc. \n* InitializeClassUnderTest - Sometimes you don't want the auto-mocking container to create your System Under Test for you.  In these cases, you can override the InitializeClassUnderTest method and assign the SUT property yourself.\n* Given - You can override the Given method to establish state and context.\n* When - You will typically override this method to invoke some action on your System Under Test.\n* BeforeEachTest - This method can be overridden when you want to execute some logic before each individual test case within a spec has executed. \n* AfterEachTest - This method can be overridden when you want to execute some logic after each individual test case within a spec has executed. \n* AfterSpec - This method is called after all your test cases within a spec have executed.  You can perform any manual cleanup here.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"SetupEachSpec\"\n}\n[/block]\nFirst, SpecsFor executes the SetupEachSpec method.  This method prepares your spec for execution by initializing the auto-mocking container, then creating your [System Under Test (SUT)](doc:the-system-under-test-sut).  \n\nNext, it executes the Given method.  This method has no behavior by default, but you can override it to establish context.\n\nFinally, the When method is executed.  Again, this method has no behavior by default, but you will typically override this method and perform actions against your SUT. \n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Then...\"\n}\n[/block]\nNow that your spec has been initialized and the Given and When methods have executed, it's time for your 'Then' test cases to execute.  Each test case is executed, followed by the AfterEachTest method.  By default, the AfterEachTest method has no behavior, but you can override this method and provide your own behavior if you need to.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"TearDown\"\n}\n[/block]\nAt this point, your specs have finished executing, so its time to clean up.  The AfterSpec method is called first.  You can override this method to provide your own cleanup logic, if needed. \n\nFinally, your spec is disposed.  If the SUT implements the IDisposable interface, it is also disposed. \n\nThis process repeats for each spec you create by deriving from the SpecsFor<T> class!","excerpt":"","slug":"specsfor-lifecycle","type":"basic","title":"SpecsFor lifecycle"}

SpecsFor lifecycle


Your spec goes through several different phases as it executes. Many of these phases can be overridden. [block:api-header] { "type": "basic", "title": "Extension Points" } [/block] While just about every step of the SpecsFor lifecycle can be overridden, you typically will only override one of the following points: * ConfigureContainer - You can override this method to change the configuration of the auto-mocking container. You can [register a concrete type](doc:register-a-concrete-type-in-the-auto-mocking-conta), load registries, etc. * InitializeClassUnderTest - Sometimes you don't want the auto-mocking container to create your System Under Test for you. In these cases, you can override the InitializeClassUnderTest method and assign the SUT property yourself. * Given - You can override the Given method to establish state and context. * When - You will typically override this method to invoke some action on your System Under Test. * BeforeEachTest - This method can be overridden when you want to execute some logic before each individual test case within a spec has executed. * AfterEachTest - This method can be overridden when you want to execute some logic after each individual test case within a spec has executed. * AfterSpec - This method is called after all your test cases within a spec have executed. You can perform any manual cleanup here. [block:api-header] { "type": "basic", "title": "SetupEachSpec" } [/block] First, SpecsFor executes the SetupEachSpec method. This method prepares your spec for execution by initializing the auto-mocking container, then creating your [System Under Test (SUT)](doc:the-system-under-test-sut). Next, it executes the Given method. This method has no behavior by default, but you can override it to establish context. Finally, the When method is executed. Again, this method has no behavior by default, but you will typically override this method and perform actions against your SUT. [block:api-header] { "type": "basic", "title": "Then..." } [/block] Now that your spec has been initialized and the Given and When methods have executed, it's time for your 'Then' test cases to execute. Each test case is executed, followed by the AfterEachTest method. By default, the AfterEachTest method has no behavior, but you can override this method and provide your own behavior if you need to. [block:api-header] { "type": "basic", "title": "TearDown" } [/block] At this point, your specs have finished executing, so its time to clean up. The AfterSpec method is called first. You can override this method to provide your own cleanup logic, if needed. Finally, your spec is disposed. If the SUT implements the IDisposable interface, it is also disposed. This process repeats for each spec you create by deriving from the SpecsFor<T> class!