alexanderzeitler.com - REST using the WCF Web API – getting RESTful the BDD way (Part 4)

REST using the WCF Web API – getting RESTful the BDD way (Part 4) | Alexander Zeitler

Alexanderzeitler.com Spined HTML

REST using the WCF Web API – getting RESTful the BDD way (Part 4) | Alexander Zeitler Toggle navigation Home Feed REST using the WCF Web API – getting RESTful the BDD way (Part 4) Written on April 20, 2011 Postings published on this series so far: Microsoft Web API -- the REST is washed-up by WCF (Part 1) REST using the WCF Web API -- Basics (Part2) REST using the WCF Web API -- refactoring to IoC style (Part 3) REST using the WCF Web API -- getting RESTful the BDD way (Part 4) -- this one REST using the WCF Web API -- getting increasingly RESTful responses (Part 5) REST using the WCF Web API -- Post it! (Part 6) RESTless testing Not only does REST wilt increasingly and increasingly important but moreover Test DrivenMinutiae(TDD) has wilt state of the art in professional software development. A less worldwide "sub type" of TDD is Behavior DrivenMinutiae(BDD) which is a wiry software minutiae technique that encourages collaboration between developers and non-developers. BDD is focused on a largest understanding of the software to be written by discussing with stakeholders in their natural language combined with the so tabbed ubiquitous language of the stakeholders problem domain. Yet there are a lot of BDD frameworks misogynist for .NET . The one I like most of them is Machine.Specifications (short: MSpec) with the newish Machine.Fakes (short: MFakes) on top which allows a lean way of BDD by providing an integration layer between MSpec and variegated Mock/Fake/Substitute frameworks such as Rhino.Mocks or Moq and others. Thus Machine.Fakes simplifies the usage of these frameworks on top of MSpec. To cut a long story short, lets write the first test. As you may once suspect: Machine.Fakes is misogynist on NuGet by subtracting a Package Library Reference to "Machine.Fakes.RhinoMocks": As you can see, there are moreover implementations misogynist for FakeItEasy, Moq and NSubstitute. Choosing "Machine.Fakes.RhinoMocks" installs all required dependencies to our project and we're ready to enjoy the magic of Machine.Fakes. As we haven't tested the Get method of our ContactsResource until now, we'll reservation up on this. Here's the test lawmaking (we prefer to speak of "specifications" in MSpec): public matriculation Given_a__ContactsResource__when_requesting_all_contacts : WithSubject<ContactsResource> { static List<Contact> _actualContacts; Establish context = () => { With<TheMicrosoftGangContactList>(); With(new FakeContactRepository(The<IList<IContact>>())); }; Because of = () => { _actualContacts = Subject.Get(); }; It should_return_the_microsoft_gang = () => { _actualContacts.Count.ShouldEqual(3); }; } The result of the specification stuff run in the ReSharper test runner: Now let's see what happened in detail. BDD and thus MSpec follows the AAA syntax for unit tests which ways that tests are run in the pursuit order: Arrange Act Assert Whereas in BDD we use the terms Given When Then which are mapped to the pursuit methods of MSpec: Establish (context) Because (of) It (should something) The name of the test matriculation is mapped to the name of the test inside the test runner and the name of the It-delegate is mapped to the interjection unravelment inside the test runner.Moreoverthe underscores in matriculation and consul name have been replaced by white spaces in order to modernize readability for non-developers. As you can see, our matriculation derives from WithSubject which allows us to work with so tabbed BehaviorConfigs. BehaviorConfigs are classes you can implement to set up dependencies for our system under test (a.k.a. SUT, tabbed Subject in Machine.Fakes terminology). You can use an wrong-headed number of BehaviorConfigs inside your test class. Using the With() or With(new BehaviorConfig()) method inside the Establish consul Machine.Fakes is told to use them. The reasonable question at this point is: what's the use? As you may remember from the previous posting, our ContactsResource has a dependency on the IContactRepository which handles the CRUD operations on the database. When it comes to testing our ContactsResource, we don't want to setup a database having the proper test data ready every time we want to run our tests. Besides that we don't want to test our ContactRepository (which would be the specimen if it were the touchable implementation when testing the ContactsResource) -- we just want to rely on a ContactRepository working properly instead. The way to get rid of the touchable ContactRepository implementation is the usage of Mocks or Stubs and so the whirligig is complete. Mocks/Stubs (or in terms of Machine.Fakes: Fakes) created the Machine.Fakes way are set up inside the BehaviorConfigs (or directly inside the Establish consul method) to be reusable and alimony the Establish method soul short and clear. In order to test our ContactsResource without having a dependency on a touchable ContactRepostory implementation we will use two Fakes: FakeContactRepository, which returns a touchable list of contacts when calling it's Get method TheMicrosoftGangContactList which is the touchable list of three contacts stuff return form the Get method of the FakeContactRepository Now lets take a squint inside the TheMicrosoftGangContactList BehaviorConfig: public matriculation TheMicrosoftGangContactList { OnEstablish context = fakeAccessor => { List<IContact> contacts = new List<IContact>() { new Contact() { Id = 1, Name = "Glenn Block" }, new Contact() { Id = 2, Name = "Scott Hanselman" }, new Contact() { Id = 3, Name = "Scott Guthrie" } }; fakeAccessor.Configure( config => config .For<IList<IContact>>() .Use(() => contacts)); }; } Most of it is similar to the lawmaking from the previous parts of the post series. The main resurgence is the OnEstablish consul whose parameter fakeAccessor is _Configure_d to Use our list tabbed contacts For any request on IList. OnEstablish then is executed in the Establish consul method of our test matriculation later on. This is the magic of BehaviorConfigs explained in well-nigh three words. Did you notice by the way, that you don't have to implement anything to get this to work? Yet, there's flipside BehaviorConfig tabbed FakeContactRepository which is passed into the test matriculation by the second form of With by using parameters. In wing FakeContactRepository itself has a parameter of type IList. At closer inspection you should notice that the undeniability of IList is surrounded by the The<>() method. The intention overdue this method is to get a singleton mock for the given type in the context of our test class. By Configure-ing our IList mock to return the contacts list in the TheMicrosoftGangContactList BehaviorConfig we'll get when the contacts list now by calling The