In this section, you will see how to start writing tests for your Nancy application. Throughout the book, I will write tests before implementation, following the red, green, refactor cycle of TDD. Consequently, you will see how to test many aspects of Nancy applications. This section just gets you started to using Nancy's testing features.
Before writing your first Nancy test, you'll need a unit testing framework and a test runner. I will be using xUnit.net
(http://xunit.codeplex.com/), but you can use whichever .NET testing framework that suits you.
The following steps will help you write tests for your Nancy application:
Open Visual Studio.
Create a new empty C# ASP.NET project and call it
TodoNancy
.Create a new C# Class Library project and call it
TodoNancyTests
.Go to Package Manager Console and write the following line of code in it:
PM> Install-Package Nancy.Testing TodoNancyTests
This pulls down the
Nancy.Testing NuGet
package and installs it into theTodoNancyTests
project. This package contains Nancy's support for testing.Go back to the Package Manager Console and write the following line of code to install the xUnit test framework:
PM> Install-Package xunit TodoNancyTests
Add a project reference to the
TodoNancy
project in theTodoNancyTests
project. This is done by right-clicking on References under the TodoNancyTests project, choosing Add Reference..., and in the dialog that opens, find the TodoNancy project under Solution | Projects. Your solution should now look like the following screenshot:There is a file called Class1.cs in the TodoNancyTests project. Rename it to
HomeModuleTests
and put the following code in it:namespace TodoNancyTests { using Nancy; using Nancy.Testing; using Xunit; public class HomeModuleTests { [Fact] public void Should_answer_200_on_root_path() { var sut = new Browser(new DefaultNancyBootstrapper()); var actual = sut.Get("/"); Assert.Equal(HttpStatusCode.OK, actual.StatusCode); } } }
This test simulates HTTP
GET "/"
to our Nancy application. We have not added any modules to our application, so it should not pass. Run the test and watch it fail. The test can be run using the xUnit.net test runner for Visual Studio (http://visualstudiogallery.msdn.microsoft.com/463c5987-f82b-46c8-a97e-b1cde42b9099) or using TestDriven.NET (http://testdriven.net/).Note the variable naming in the test. They are a part of another set of conventions I like to follow. The
sut
variable is the thing being tested. It is short for system under test. Theactual
variable is the result of what the test does to the production code. Consequently,actual
usually holds the value asserted at the end of the test.Add the Nancy framework to the
TodoNancy
project, and enable running on top of ASP.NET by going to Package Manager Console and typing in this command:PM> Install-Package Nancy.Hosting.Aspnet TodoNancy
To make the test pass, we need to add a new C# file to the root of the
TodoNancy
project. Let's call itHelloModule
and add the following code to it:namespace TodoNancy { using Nancy; public class HomeModule : NancyModule { public HomeModule() { Get["/"] = _ => HttpStatusCode.OK; } } }
Your Solution Explorer should now look more or less as the following screenshot:
Re-run the test from beginning and watch it succeed.
Congratulations! You just created your first piece of the Nancy application code in a test-first fashion.
Taking a closer look at the test code, the first thing to notice is the following line of code:
var sut = new Browser(new DefaultNancyBootstrapper());
This creates an instance of the Browser
class from the Nancy.Testing
namespace, which is an essential type of object while testing Nancy modules. The Browser
type allows making calls that simulate real HTTP requests without neither the Nancy framework, nor your application code knowing the difference. Furthermore, these simulated requests are made without actually going through the network stack. This is important because it gives you the opportunity to write tests that are both fast and run against the API you expose to clients; for example, browsers.
The next thing to note is the following line of code:
var actual = sut.Get("/");
This line uses the Get
method of the Browser
object, which will create what appears to the Nancy framework as an HTTP GET request to the path provided as the first argument—in this case "/"
. This is done in-process and does not involve the network stack, which means that it is a lot faster and easier to set up than tests that make full-fledged real HTTP requests. Also worth noting is how this testing syntax aligns nicely with the syntax used in the Nancy module to set up the handler for the route.
The return value from the call to Get
is a BrowserResponse
class—another class from the Nancy.Testing
namespace. The BrowserResponse
class gives the tests the access to everything returned from the route handler as well as everything Nancy added to that response. The different parts of the response can be reached through the properties such as StatusCode
, Headers
, Cookies
, and Body
. In the test we wrote in the previous section, we just read StatusCode
and asserted that it was 200 OK
.
The Browser
type not only supports in making simulated HTTP GET
requests but also supports the other HTTP verbs through the methods Post
, Delete
, Put
, Patch
, Options
, and Head
, it. Each of these methods is used in a similar fashion to Get
. In later recipes, we will see how to specify the body of the simulated HTTP request; for example, a call to Post
. We will also see how to set HTTP headers for calls made through the Browser
objects.
Furthermore, if you want a test to make a sequence of calls to your API, you can do this by using the Then
method on the BrowserResponse
class. The Then
method allows you to chain simulated HTTP requests one after the other in the following manner:
var actual = sut.Get("/").Then.Get("/foo");
Lastly, Nancy.Testing
includes some convenient methods for asserting against the contents of the body of responses when the body is either JSON, XML, or HTML. We will see these features in the upcoming recipes as we will actually start returning something from our route handlers.