How it works...

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.