Incremental development with Monorail: Part Six
We finished up in part five with a full suite of passing tests and our BlogPostService is slowly taking shape now. The next few posts will introduce persistence and validation but before we get started on these features, we have a little housekeeping to perform on our existing code.
First step is to build the Castle trunk and update our references to the latest versions. Secondly, we’ll incorporate a few changes suggested by Hammett.
After building and replacing our references with the latest Castle build I’ll run the tests as a sanity check before we proceed:
With that out of the way our first code change will ensure we play nicely with HTTP. It is considered good practice to ensure requests which update or create resources is carried out via POST – so we can modify our only PostController.Save action to ensure this is so but before we do this we’ll write a test:
Running our test produces the following:
We’ll modify our Save action now to ensure we only accept the POST verb:
We have added the AccessibleThrough attribute and explicitly specified that our action must only allow the POST verb. We’ll run our test again and make sure everything is working as expected:
The next step is to modify our add.vm view to use the helper methods to generate our form tags. We’ve done that and once again we’ll run our tests:
I’m noticing a little duplication creeping in to our integration tests that should be removed. Also, until now we’ve had to assume that a web server is running on a specific port on our development machine in order to run the integration tests. Through a little tweaking we can spin-up a temporary server in our test fixture setup code and host our test code there instead.
First we add the WebDev.WebHost.dll to our lib project directory and ensure we’re referencing this from the testing project. The next step is to create an app.config file in the testing project so we can configure where and from which port our testing server should be hosting from:
We’ll also make sure we bring the server down when we’re finished:
Now ensure the VS web server is not running on the same port, then we can run our tests and make sure our latest changes work out:
Now, since we specify the web root and port through configuration, we should also use these configurable values to determine the URLs in our tests:
You can see our tests now call BuildTestUrl to determine the full URL where we’re hosting the development server. Neat. I’m sure when we add further integration fixtures we’ll extract class this, but for now we have a nice working set of tests and should remember the principle of YAGNI!
I’m going to cut this installment short here. In the next post we’ll get back into the swing of it and continue implementing features.
As ever, the latest code has been checked in and is available here: