Testing Actions Not Dependent on the Controller Context

In these tests, we test the action as we would any other method. Let’s look at the action again:

public IEnumerable<Order> Get()
{
     return _orderService.GetAll();
}

You can see there is very little to test. Some might argue there is not a lot of value to test this method. At the end of the day, you need to make a judgment on the level of the testing required, but in order to test all you need do is make sure _orderService is called and returns GetAll as a result. Let’s create a mock object and pass it to the constructor to supply the dependency (see Listing 15-3).

Listing 15-3.  Testing GetAll()

[Fact]
public void GetAll_should_return_all_from_OrderService()
{
    // arrange
    var orders = new Order[0];
    var mockOrderService = new Mock<IOrderService>();
    mockOrderService.Setup(x => x.GetAll())
                .Returns(orders);
    var orderController = new OrderController(mockOrderService.Object);
             
    // act
    var result = orderController.Get();

    // assert
    Assert.Equal(orders, result);
}

Testing Actions with Limited Dependency on the Context

Now let’s look at the Get action, where the order Id is passed. You start by writing the test and then improve it step by step. In this case, the item is returned if it exists; otherwise HTTP status 404 (Not Found) is returned:

public HttpResponseMessage Get(HttpRequestMessage request, int id)
{
    if (!_orderService.Exists(id))
        return request.CreateErrorResponse(HttpStatusCode.NotFound, "Order does not exist");

    return request.CreateResponse(HttpStatusCode.OK,  _orderService.Get(id));
}

Testing this action involves two tests: one where order exists, and one where it does not. So let’s write the first test (shown in Listing 15-4).

Listing 15-4.  Testing Getting an Existing Order Without Preparing the Request Context (Causes Exception)

[Fact]
public void Get_should_return_OK_if_order_exists()
{
    // arrange
    const int OrderId = 123;
    var order = new Order()
                    {
                        Id = OrderId
                    };
    var mockOrderService = new Mock<IOrderService>();
    mockOrderService.Setup(x => x.Exists(It.IsAny<int>()))
                .Returns(true);

    mockOrderService.Setup(x => x.Get(It.IsAny<int>()))
        .Returns(order);
    var orderController = new OrderController(mockOrderService.Object);

    // act
    var result = orderController.Get(new HttpRequestMessage(),  OrderId);

    // assert
    Assert.Equal(HttpStatusCode.OK, result.StatusCode);
}

This test looks all well and good, but when it is run, we get an error:

System.InvalidOperationException
The request does not have an associated configuration object or the provided configuration was null.
   at System.Net.Http.HttpRequestMessageExtensions.CreateResponse(HttpRequestMessage request,
HttpStatusCode statusCode, T value, HttpConfiguration configuration)
   at System.Net.Http.HttpRequestMessageExtensions.CreateResponse(HttpRequestMessage request,
HttpStatusCode statusCode, T value)
   at PizzaApi.Api.Controllers.OrderController.Get(HttpRequestMessage request, Int32 id) in OrderController.cs: line 37
   at PizzaApi.Api.Tests.OrderControllerTests.Get_should_return_OK_if_exists() in OrderControllerTests.cs: line 54

The test complains about the configuration object being null, but since HttpConfiguration was not used at all, where does it need to use the configuration? Remember from previous chapters that HttpRequestMessage contains a property bag, named Properties, that contains context-related properties of the request. This design has the benefit of not relying on the HttpContext.Current, but you need to supply the configuration when you create the request. So let’s rewrite the test (see Listing 15-5).

Listing 15-5.  Testing Getting an Existing Order with Setting the Request Property

[Fact]
public void Get_should_return_OK_if_order_exists()
{
    // arrange
    const int OrderId = 123;
    var order = new Order()
                    {
                        Id = OrderId
                    };

    var mockOrderService = new Mock<IOrderService>();
    mockOrderService.Setup(x => x.Exists(It.IsAny<int>()))
                .Returns(true);

    mockOrderService.Setup(x => x.Get(It.IsAny<int>()))
        .Returns(order);
    var orderController = new OrderController(mockOrderService.Object);
    var request = new HttpRequestMessage();
    request.Properties[HttpPropertyKeys.HttpConfigurationKey] = new HttpConfiguration();

    // act
    var result = orderController.Get(request,  OrderId);

    // assert
    Assert.Equal(HttpStatusCode.OK, result.StatusCode);
}

Now the test passes without an exception. So now you can write a test for the case where an Id does not exist (see Listing 15-6).

Listing 15-6.  Testing Getting a Nonexisting Order

[Fact]
public void Get_should_return_NotFound_if_order_DoesNotExistS()
{
    // arrange
    const int OrderId = 123;
    var mockOrderService = new Mock<IOrderService>();
    mockOrderService.Setup(x => x.Exists(It.IsAny<int>()))
                .Returns(false);

    var orderController = new OrderController(mockOrderService.Object);
    var request = new HttpRequestMessage();
    request.Properties[HttpPropertyKeys.HttpConfigurationKey] = new HttpConfiguration();

    // act
    var result = orderController.Get(request, OrderId);

    // assert
    Assert.Equal(HttpStatusCode.NotFound, result.StatusCode);
}

Now let’s look at the Delete action (see Listing 15-7). This action can be tested in a similar way, since it does not access controller context. Delete first checks to see whether the item exists. If it does, Delete deletes it and returns HTTP status 200 (OK); otherwise HTTP status 404 (Not Found) is returned.

Listing 15-7.  Implementing Delete in OrderController

public HttpResponseMessage Delete(HttpRequestMessage request, int id)
{
    if (!_orderService.Exists(id))
        return request.CreateErrorResponse(HttpStatusCode.NotFound, "Order does not exist");

    _orderService.Delete(id);
    return Request.CreateResponse(HttpStatusCode.OK);
}

Writing tests for the PUT and DELETE methods is very similar to writing them for GET, and so there is no need to go into the matter here.

Testing Actions Dependent on Controller Context

Now let’s look at the POST action. This method

1. Checks to make sure an order contains order items. If the order is invalid, the action returns a “Bad Request” error.
2. Checks to make sure an Id does not exist. If it does, a “Bad Request” error is returned.
3. Saves the order.
4. Creates a response with Created (201) HTTP status and creates an address for the new order in the Location header.

Step 3 is implemented by the IServiceOrder—since it is stubbed, it does not need to be tested, and hence three tests are needed for this method. The first two tests are easy to implement and very similar to previous tests. So let’s look at testing the fourth step.

This is where things get interesting. Let us just create a test similar to those already done (see Listing 15-8).

Listing 15-8.  Testing HTTP Status Code for a Valid Order Without Preparing Controller Context

[Fact]
public void Post_should_return_Created_if_order_good()
{
    // arrange
    const int OrderId = 123;
    var order = new Order(new OrderItem[]
                                {
                                    new OrderItem()
                                        {
                                            Name = "Name",
                                            Quantity = 1
                                        }
                                })
    {
        Id = OrderId
    };
    var mockOrderService = new Mock<IOrderService>();
    mockOrderService.Setup(x => x.Exists(It.IsAny<int>()))
                .Returns(false);

    var orderController = new OrderController(mockOrderService.Object);
    var request = new HttpRequestMessage();
    request.Properties[HttpPropertyKeys.HttpConfigurationKey] = new HttpConfiguration();

    // act
    var result = orderController.Post(request, order);

    // assert
    Assert.Equal(HttpStatusCode.Created, result.StatusCode);
}

Running this test results in a null exception:

System.ArgumentNullException
Value cannot be null.
Parameter name: request
at System.Web.Http.ApiController.get_Url()

As you see, the problem is that the Url property of the controller is null since it has not been set up. It is time to set up the controller context, as our implementation depends upon it. For the Url property to work, the controller context must be set. The code in Listing 15-9 does exactly that.

Listing 15-9.  Testing HTTP Status Code for a Valid Order Without Preparing Controller Context

[Fact]
public void Post_should_return_Created_if_order_good()
{
    // arrange
    const int OrderId = 123;
    var order = new Order(new OrderItem[]
                                {
                                    new OrderItem()
                                        {
                                            Name = "Name",
                                            Quantity = 1
                                        }
                                })
    {
        Id = OrderId
    };
    var mockOrderService = new Mock<IOrderService>();
    mockOrderService.Setup(x => x.Exists(It.IsAny<int>()))
                .Returns(false);

    var orderController = new OrderController(mockOrderService.Object);
    var request = new HttpRequestMessage(HttpMethod.Post, "http://localhost:2345/api/Order/");
    var config = new HttpConfiguration();
    request.Properties[HttpPropertyKeys.HttpConfigurationKey] = config;
    orderController.Request = request;
    orderController.Configuration = config;
    config.Routes.MapHttpRoute("DefaultApi", "api/{controller}/{id}", _
        new {id = RouteParameter.Optional});
    var route = config.Routes["DefaultApi"];
    var httpRouteData = new HttpRouteData(route, new HttpRouteValueDictionary( _
        new {controller = "Order" }));
    orderController.Request.Properties[HttpPropertyKeys.HttpRouteDataKey] = httpRouteData;
             
    // act
    var result = orderController.Post(request, order);

    // assert
    Assert.Equal(HttpStatusCode.Created, result.StatusCode);
}

The code in Listing 15-9 works but is verbose, and setting up the context in each test, as we have done, will reduce readability. So to make the code more readable, let’s devise a helper that can be used to create and set up the controller and its context. The ControllerContextSetup class has been created—you can find it in the book’s samples—and it exposes a Fluent API for context setup. The test in Listing 15-10 uses the ControllerContextSetup class.

Listing 15-10.  Using the Data Builder’s Fluent API to Set Up the Controller Context

[Fact]
public void Post_should_return_Created_if_order_good_fluentApi()
{
    // arrange
    const int OrderId = 123;
    var order = new Order(new OrderItem[]
                                {
                                    new OrderItem()
                                        {
                                            Name = "Name",
                                            Quantity = 1
                                        }
                                })
    {
        Id = OrderId
    };
    var mockOrderService = new Mock<IOrderService>();
    mockOrderService.Setup(x => x.Exists(It.IsAny<int>()))
                .Returns(false);

    var orderController = ControllerContextSetup
        .Of(() => new OrderController(mockOrderService.Object))
        .WithDefaultConfig()
        .WithDefaultRoute()
        .Requesting("http://localhost:2345/api/Order/")
        .WithRouteData(new {controller="Order"})
        .Build<OrderController>();

    // act
    var result = orderController.Post(orderController.Request, order);
             
    // assert
    Assert.Equal(HttpStatusCode.Created, result.StatusCode);
}

Great! You now have 100 percent coverage of the controller. Is there anything missing? Let’s look at the test in Listing 15-10: does it cover all functionality of the SUT—that is, the system under test (the Post action here)? Not really. You have not yet checked the content or the location header.

So more assertions are needed. However,it is generally accepted that every test needs to check only one piece of functionality. In effect, this means that you can have similar tests with only the assertions being different. This is also not ideal, but you will see later how to use SubSpec to overcome this problem. For now let’s add more assertions to the test. After defining URL as a constant and adding more assertions, the code looks like Listing 15-11.

Listing 15-11.  Adding more assertions

[Fact]
public void Post_should_return_Created_if_order_good_fluentApi()
{
    // arrange
    const string url = "http://localhost:2345/api/Order/";
    const int OrderId = 123;
    var order = new Order(new OrderItem[]
                                {
                                    new OrderItem()
                                        {
                                            Name = "Name",
                                            Quantity = 1
                                        }
                                })
    {
        Id = OrderId
    };
    var mockOrderService = new Mock<IOrderService>();
    mockOrderService.Setup(x => x.Exists(It.IsAny<int>()))
                .Returns(false);

    var orderController = ControllerContextSetup
        .Of(() => new OrderController(mockOrderService.Object))
        .WithDefaultConfig()
        .WithDefaultRoute()
        .Requesting(url)
        .WithRouteData(new {controller="Order"})
        .Build<OrderController>();

    // act
    var result = orderController.Post(orderController.Request, order);
             
    // assert
    Assert.Equal(HttpStatusCode.Created, result.StatusCode);
    Assert.NotNull(result.Headers.Location);
    Assert.Equal(result.Headers.Location, new Uri(new Uri(url), order.Id.ToString()));
}

SubSpec helps to define each assertion by means of a separate test (this is examined later in the chapter).

Testing GetRouteData and GetVirtualPath

As we said, GetRouteData matches URL to a route and extracts its parameters. To test it, create an instance of HttpConfiguration, and pass it to static Register method of WebApiConfig class (see Listing 15-13).

Listing 15-13.  Data-Driven Cases for Testing Routing

[Theory]
[InlineData("http://localhost:12345/foo/route", "GET", false, null, null)]
[InlineData("http://localhost:12345/api/order/", "GET", true, "order", null)]
[InlineData("http://localhost:12345/api/order/123", "GET", true, "order", "123")]
public void DefaultRoute_Returns_Correct_RouteData(
    string url, string method, bool shouldfound, string controller, string id)
{
    // arrange
    var config = new HttpConfiguration();
    WebApiConfig.Register(config);
    var request = new HttpRequestMessage(new HttpMethod(method), url);
             
    // act
    var routeData = config.Routes.GetRouteData(request);

    // assert
    Assert.Equal(shouldfound, routeData!=null);
    if (shouldfound)
    {
        Assert.Equal(controller, routeData.Values["controller"]);
        Assert.Equal(id == null ? (object) RouteParameter.Optional : (object)id, routeData.Values["id"]);
    }
}

To test the routing in Listing 15-13, call the Register method to initialize the configuration. Instead of using the Fact attribute, use the Theory attribute along with InlineData to create a data-driven test. Each InlineData attribute defines one test, and parameters defined in each InlineData attribute are passed to the test method. As Figure 15-3 shows, each InlineData case appears as a separate test. You can also add a parameter for the route name to ensure that the URL is mapped to the correct route name.

Now let’s add a test for the OrderItems route:

[InlineData("http://localhost:12345/api/order/123/OrderItem/456",  _
"GET", true, "OrderItem", "123")]

This will ensure that the second added route works. Testing GetVirtualPath is also very similar, the difference being that the parameters are passed and the resultant path checked on the other side. Testing GetVirtualPath does not have a lot of value, and some exclude it from their coverage.

Testing Controller and Action Selection

Testing routes is very important, especially when you have many routes and the likelihood of route collision is high. But even checking that the correct route is selected and the correct route data are extracted does not ensure that the correct controller and action are selected. But not to worry! It is possible to test that, too.

As you learned in previous chapters, the controller selector (an implementation of IHttpControllerSelector) and the action selector (an implementation of IHttpActionSelector) are used by the framework to find the appropriate controller and action. It is not very difficult to run the same process in your tests so as to ensure correct selection of the controller and action—especially if you have replaced default services with your own. This test complements your routing tests, and so in a sense it is an integration test rather than a unit test. Either way, it is very important. You can write the tests in two ways:

• Relying on the routing result to be correct—hence, an integration test
• Providing your own route data to decouple the test from routing

The second option looks purer and more decoupled, but as it requires more setup, it can lead to less readable tests. We prefer the first option, since we prefer simplicity and readability and believe controller/action selection is an integration test anyway. We employ data-driven tests using the Theory attribute in Listing 15-14.

Listing 15-14.  Data-Driven Cases for Checking Controller and Action Selection

[Theory]
[InlineData("http://localhost:12345/api/order/123", "GET", typeof(OrderController), "Get")]
[InlineData("http://localhost:12345/api/order", "POST", typeof(OrderController), "Post")]
[InlineData("http://localhost:12345/api/order/123", "PUT", typeof(OrderController), "Put")]
[InlineData("http://localhost:12345/api/order", "GET", typeof(OrderController), "Get")]
[InlineData("http://localhost:12345/api/order/123/OrderItem", "GET", typeof(OrderItemController), "GetItems")]
public void Ensure_Correct_Controller_and_Action_Selected(
    string url,
    string method,
    Type controllerType,
    string actionName)
{
    // arrange
    var config = new HttpConfiguration();
    WebApiConfig.Register(config);
    var actionSelector = config.Services.GetActionSelector();
    var controllerSelector = config.Services.GetHttpControllerSelector();
    var request = new HttpRequestMessage(new HttpMethod(method), url);
    var routeData = config.Routes.GetRouteData(request);
    request.Properties[HttpPropertyKeys.HttpRouteDataKey] = routeData;
    request.Properties[HttpPropertyKeys.HttpConfigurationKey] = config;
             
    // act
    var controllerDescriptor = controllerSelector.SelectController(request);
    var context = new HttpControllerContext(config, routeData, request)
                        {
                            ControllerDescriptor = controllerDescriptor
                        };
    var actionDescriptor = actionSelector.SelectAction(context);

    // assert
    Assert.Equal(controllerType, controllerDescriptor.ControllerType);
    Assert.Equal(actionName, actionDescriptor.ActionName);
}

SpecFlow

SpecFlow,a Visual Studio plug-in and library, implements Gherkin language and links its wiring to unit-testing frameworks. SpecFlow—not itself a testing framework—works with all popular unit-testing frameworks, including NUnit and xUnit.

In SpecFlow you start with the features of your system. Then stakeholders start to define one or more acceptance tests as scenario. Each scenario is composed of one or more Given statements, one When statement, and one or more Then statements. These are defined in a feature file (see Figure 15-5), and multiple statements are separated using And.

Each Given/When/Then is mapped to a step. A step is the code implementation of the statement. These steps are methods in a class, methods that have Given, When and Then attributes defined against them. These attributes accept a string parameter that is the text of the statement. Let’s look at SpecFlow in more detail and use it to write our integration tests.

SubSpec

SubSpec,an add-on to the xUnit framework, enables more readable BDD-style unit/integration tests. It defines Context, Do, and one or more Observation instances (analogous to Given, When, and Then) and helps define multiple assertions inside the test while making each one a separate test.

Since SubSpec tests use string extension methods, you can use strings (instead of comments) to define the requirement. Unlike typical xUnit tests, which are defined by [Fact] or [Theory] attributes, it uses a [Specification] attribute.

In order to use SubSpec, add it to your project using NuGet:

PM> Install-Package SubSpec

In order to demonstrate how to write unit/integration tests in SubSpec, let’s rewrite GetAll_should_return_all_from_OrderService in SubSpec (see Listing 15-18).

Listing 15-18.  Writing Multiple Assertions in SubSpec

[Specification]
public void GetAll_should_return_all_from_OrderService_Subspec()
{
             
    var orders = default(Order[]);
    var mockOrderService = default(Mock<IOrderService>);
    var orderController = default(OrderController);
    var result = default(IEnumerable<Order>);

    "Given order service contains no orders"
        .Context(() =>
                        {
                            orders = new Order[0];
                            mockOrderService = new Mock<IOrderService>();
                            orderController = new OrderController(mockOrderService.Object);
                            mockOrderService.Setup(x => x.GetAll())
                                            .Returns(orders);
                        });

    "When I ask for all orders from orderController"
        .Do(() =>
                {
                    result = orderController.Get();
                });
    "Then it must not be null"
        .Observation(() =>
                            {
                                Assert.NotNull(result);
                            });
    "And it should contain no order"
        .Observation(() =>
                            {
                                Assert.Empty(result);
                            });
}

Tests of this style differ from tests with SpecFlow in that these tests are suited for writing (and reading) only by the developers. They are thus better suited for unit tests than integration tests.

Integration Testing for Content Negotiation

We all rely on the framework to implement content negotiation and to return the correct format if it is requested by the client. Given that, we could be adding, removing, or replacing MediaTypeFormatters. Also, we could define ViewModel types that some formatters might have a problem serializing or deserializing. All in all, the importance of integration testing cannot be overemphasized.

OK, let’s start with the first SpecFlow feature by adding the Formatting.feature file with the content shown in Listing 15-19.

Listing 15-19.  Feature File Using Gherkin Syntax

Feature: Formatting
               In order to get orders data
               As an API client
               I want to be able to define the format

@normal
Scenario Outline: Get back data with the format requested
               Given I provide format <Format>
               When I request for all orders
               Then I get back <ContentType> content type
                              And content is a set of orders
               Examples:
               | Format | ContentType      |
               | JSON   | application/json |
               | XML    | application/xml  |

As you can see from the use of Scenario Outline, this is a data-driven test. In a Scenario Outline the data are defined in the Examples section using a table. Each row defines one test, with data of the row as the parameters passed to the test.

Now steps to map each statement to the code need to be created. An easy way to do this is to right-click on the feature file and select “Generate Step Definitions”. A step is just a method in a class which has a [Binding] attribute. A [Binding] attribute tells SpecFlow to look for step definition methods.

Steps can be reused from one scenario to another if the statement is the same. So although the Gherkin syntax is very close to free text, be consistent in terms of the statement text. Keep them the same if they refer to the same action or condition.

Let’s implement the steps. Listing 15-20 shows the step definitions. Note that parameters defined in statements using angle brackets—for example <Format>—are defined as regular expression statements.

Listing 15-20.  Code for Steps Related to the Feature File in Listing 15-19

[Binding]
public class FormattingSteps
{

    private const string Url = "http://localhost:12345/api/Order";
    private string _format = null;
    private HttpResponseMessage _response;

    [Given(@"I provide format (.+)")]
    public void GivenIProvideFormat(string format)
    {
        _format = format;
    }

    [When(@"When I request for all orders")]
    public void WhenIRequestOrderData()
    {
        var request = new HttpRequestMessage(HttpMethod.Get, Url);
        var server = new VirtualServer(WebApiConfig.Register,
            Convert.ToBoolean(ConfigurationManager.AppSettings["UseSelfHosting"]));
        request.Headers.Accept.Clear();
        request.Headers.Accept.Add( new MediaTypeWithQualityHeaderValue(
            _format == "JSON" ? "application/json" : "application/xml"));
        _response = server.Send(request);
    }

    [Then(@"I get back (.+) content type")]
    public void ThenIGetBackContentType(string contentType)
    {
        Assert.Equal(contentType, _response.Content.Headers.ContentType.MediaType);
    }

    [Then(@"content is a set of orders")]
    public void ThenContentIsASetOfOrders()
    {
        var content = _response.Content.ReadAsAsync<IEnumerable<Order>>().Result;
    }
}

Also note that we have defined the flag to use self-hosting or not as an appSettings key in the app.config file. You can flip the value to true or false depending on which one you prefer.

The code in Listing 15-20 uses a class called VirtualServer (see Listing 15-21), which abstracts whether to use self-hosting or HttpServer.

Listing 15-21.  Code for a VirtualServer class That Executes a Request Using a Self-Hosted or HttpServer

public class VirtualServer
{
    private readonly bool _useSelfHosting;
    private readonly Action<HttpConfiguration> _setupConfiguration;

    public VirtualServer(Action<HttpConfiguration> setupConfiguration, bool useSelfHosting = false)
    {
        _setupConfiguration = setupConfiguration;
        _useSelfHosting = useSelfHosting;
    }

    public HttpResponseMessage Send(HttpRequestMessage request)
    {
        return _useSelfHosting ? SendSelfHosted(request) : SendHttpServer(request);
    }

    private HttpResponseMessage SendHttpServer(HttpRequestMessage request)
    {
        var config = new HttpConfiguration();
        _setupConfiguration(config);
        var server = new HttpServer(config);
        var invoker = new HttpMessageInvoker(server);
        return invoker.SendAsync(request, new CancellationToken())
            .Result;
    }

    private HttpResponseMessage SendSelfHosted(HttpRequestMessage request)
    {
        var config = new HttpSelfHostConfiguration(new Uri("http://localhost :" +
            request.RequestUri.Port));
        _setupConfiguration(config);
        using (var host = new HttpSelfHostServer(config))
        {
            host.OpenAsync().Wait();
            var client = new HttpClient();
            var response = client.SendAsync(request).Result;
            host.CloseAsync().Wait();
            return response;
        }
    }
}

Once this is done, you can run or debug your integration tests by right-clicking the feature file and choosing the run/debug scenario. The tests also can be triggered using test-running tools (such as Resharper), and you may choose to run them there.

Our tests’ current implementation works, but use of local member variables will prevent reuse of our steps. The next section introduces a technique to remove all member variables.

Integration Testing for Placing the Order

Now an integration test for placing the order would be great to have. Here we use Scenario instead of Scenario Outline. Also, this time we use the ScenarioContext.Current object rather than member variables for keeping the context. Using ScenarioContext is the preferred approach. In BDD terms, ScenarioContext is the “world”—that is, the context in which a test is running.

So let’s add the PlaceOrder.featurefile and write the feature and a scenario (see Listing 15-22).

Listing 15-22.  PlaceOrders Feature File

Feature: PlaceOrders
               In order to inform kitchen of the customer orders
               As a pizza shop operator
               I want to be able to place customer orders

@normal
Scenario: Placing order
               Given I have an order for a mixture of pizzas
                              And it is for a particular customer
               When I place the order
                              And retrieve the order
               Then system must have priced the order
                              And system must have saved the order
                              And saved order must contain same pizzas
                              And saved order must have the name of the customer

Here we make sure that the order is saved and, when retrieved, contains the same data. We also check that the price is calculated. To do this, we need to make some changes in the VirtualServer class so that it keeps its state between requests (see Listing 15-23).

Listing 15-23.  Updated VirtualServer

public class VirtualServer : IDisposable
{
    private readonly bool _useSelfHosting;
    private readonly Action<HttpConfiguration> _setupConfiguration;
    private Func<HttpRequestMessage, Task<HttpResponseMessage>> _invoker;
    private HttpSelfHostServer _server;

    public VirtualServer(Action<HttpConfiguration> setupConfiguration, bool useSelfHosting = false)
    {
        _setupConfiguration = setupConfiguration;
        _useSelfHosting = useSelfHosting;
        if (useSelfHosting)
        {
            var config = new HttpSelfHostConfiguration(new Uri(ConfigurationManager.
                AppSettings["BaseUrl"]));
            _setupConfiguration(config);
            _server = new HttpSelfHostServer(config);
            _server.OpenAsync().Wait();
            var client = new HttpClient();
            _invoker = client.SendAsync;
        }
        else
        {
            var config = new HttpConfiguration();
            _setupConfiguration(config);
            var server = new HttpServer(config);
            _invoker = (req) =>
                            {
                                return new HttpMessageInvoker(server).SendAsync(req,
                                    new CancellationToken());
                            };
        }
    }

    public HttpResponseMessage Send(HttpRequestMessage request)
    {
        return _useSelfHosting ? SendSelfHosted(request) : SendHttpServer(request);
    }

    private HttpResponseMessage SendHttpServer(HttpRequestMessage request)
    {
            
        return _invoker(request)
            .Result;
    }

    private HttpResponseMessage SendSelfHosted(HttpRequestMessage request)
    {
        return _invoker(request)
                .Result;
    }

    public void Dispose()
    {
        if (_server != null)
        {
            _server.CloseAsync().Wait();
            _server.Dispose();
            _server = null;
        }
    }
}

Now we are ready to create our steps. But to make sure the server is created and destroyed at the right time, we need to use two SpecFlow hooks: BeforeScenario and AfterScenario. As the names imply, these hooks run, respectively, before and after the scenario steps (see Listing 15-24).

Listing 15-24.  Steps for the PlaceOrder Feature

[Binding]
public class PlaceOrdersSteps
{
         
    [BeforeScenario]
    public void CreateVirtualServer()
    {
            var server = new VirtualServer(WebApiConfig.Register,
            Convert.ToBoolean(ConfigurationManager.AppSettings["UseSelfHosting"]));
            ScenarioContext.Current[TestContextKeys.VirtualServer] = server;
    }

    [AfterScenario]
    public void DisposeVirtualServer()
    {
        var server = ScenarioContext.Current.Get<VirtualServer>(TestContextKeys.VirtualServer);
        if (server != null)
        {
            server.Dispose();
        }

    }

    [Given(@"I have an order for a mixture of pizzas")]
    public void GivenIHaveAnOrderForAMixtureOfPizzas()
    {
        var order = new Order();
        order.Items = new[]
                            {
                                new OrderItem()
                                    {
                                        Name = "Hawaiian",
                                        Quantity = 2
                                    },
                                    new OrderItem()
                                        {
                                            Name = "Meat Feast",
                                            Quantity = 1
                                        }
                            };
        ScenarioContext.Current[TestContextKeys.NewOrder] = order;
    }
         
    [Given(@"it is for a particular customer")]
    public void GivenItIsForAParticularCustomer()
    {
        const string CustomerName = "SomeCustomer";
        var order = ScenarioContext.Current.Get<Order>(TestContextKeys.NewOrder);
        ScenarioContext.Current[TestContextKeys.CustomerName] = CustomerName;
        order.CustomerName = CustomerName;
    }
         
    [When(@"I place the order")]
    public void WhenIPlaceTheOrder()
    {
        var request = new HttpRequestMessage(HttpMethod.Post,  _
               ConfigurationManager.AppSettings["BaseUrl"]
            + "api/Order");
        var server  = ScenarioContext.Current.Get<VirtualServer>(TestContextKeys.VirtualServer);
        var newOrder = ScenarioContext.Current.Get<Order>(TestContextKeys.NewOrder);
        request.Content = new ObjectContent<Order>(newOrder, new JsonMediaTypeFormatter());
        ScenarioContext.Current[TestContextKeys.Request] = request;
        var response = server.Send(request);
        ScenarioContext.Current[TestContextKeys.Response] = response;
        ScenarioContext.Current[TestContextKeys.OrderUrl] = response.Headers.Location;

    }

    [When(@"retrieve the order")]
    public void WhenRetrieveTheOrder()
    {
        var server = ScenarioContext.Current.Get<VirtualServer>(TestContextKeys.VirtualServer);
        var request = new HttpRequestMessage(HttpMethod.Get,
            ScenarioContext.Current.Get<Uri>(TestContextKeys.OrderUrl));
        var response = server.Send(request);
        var retrievedOrder = response.Content.ReadAsAsync<Order>().Result;
        ScenarioContext.Current[TestContextKeys.RetrievedOrder] = retrievedOrder;
    }

    [Then(@"system must have priced the order")]
    public void ThenSystemMustHavePricedTheOrder()
    {
        var retrievedOrder = ScenarioContext.Current.Get<Order>(TestContextKeys.RetrievedOrder);
        Assert.True(retrievedOrder.TotalPrice > 0);
    }

    [Then(@"system must have saved the order")]
    public void ThenSystemMustHaveSavedTheOrder()
    {
        var retrievedOrder = ScenarioContext.Current.Get<Order>(TestContextKeys.RetrievedOrder);
        Assert.True(retrievedOrder.Id != 0);
    }

    [Then(@"saved order must contain same pizzas")]
    public void ThenSavedOrderMustContainSamePizzas()
    {
        var retrievedOrder = ScenarioContext.Current.Get<Order>(TestContextKeys.RetrievedOrder);
        var newOrder = ScenarioContext.Current.Get<Order>(TestContextKeys.NewOrder);
        Assert.Equal(newOrder.Items.Count(), retrievedOrder.Items.Count());
        Assert.Equal(newOrder.Items.First().Name, retrievedOrder.Items.First().Name);
        Assert.Equal(newOrder.Items.First().Quantity, retrievedOrder.Items.First().Quantity);
    }
         
    [Then(@"saved order must have the name of the customer")]
    public void ThenSavedOrderMustHaveTheNameOfTheCustomer()
    {
        var retrievedOrder = ScenarioContext.Current.Get<Order>(TestContextKeys.RetrievedOrder);
        var customerName = ScenarioContext.Current.Get<string>(TestContextKeys.CustomerName);
        Assert.Equal(customerName, retrievedOrder.CustomerName);
    }
}

OK, now our scenario is ready to run. Note that the use of ScenarioContext to avoid member variables will help to share steps, since the step relies on no context other than ScenarioContext.Current.

Creating other integration tests for other features of the system is more or less the same. As noted earlier, some common steps can be reused, such as the “retrieve the order” step which uses the order URL to retrieve the order from the server.