experiments in context specification

In my spare time I've been working with new ways of writing tests at all levels such as unit, integration and acceptance, and one thing remains constant in all these experiments - the need to have the tests be expressive so that they easily communicate their intent and have them as readable as possible to an alien eye, be it another developer, a tester or a business analyst or product owner.

The traditional style of unit testing has a certain way of forcing us to think in intricate implementation detail and this is expressed very well by Scott Bellware on his podcast with the Herding Code guys.

Over the next few posts I'm hopefully going to try and illustrate my current way of writing tests using a context specification style that allows the tests to be more behaviour driven and encourages the developer to think differently about both the test and how the code they are writing will be consumed.
This is by no means a definitive statement of how beahviour driven testing should be but more my journey into a better way of doing things.

I've decided to create an example project that deals with personal finance management - it is not meant to be a thorough application by any means, but will hopefully provide some rich behaviours that I will need to model. More importantly I'm sure there will be many different contexts that will crop up and allow me to see the fruit of the context specification style in action.
Rather than present the finished article when illustrating the code I will aim to show the progress of the code in all forms of good, bad and the ugly.

The library I'm using to develop my tests is the developwithpassion.bdd library from Jean-Paul Boodhoo.

This project forms an expressive wrapper on top of mbunit that turns the library into a context driven one with Act-Arrange-Assert style syntax. It also wraps Rhino Mocks with extension methods to make them more expressive. Where possible I will try and communicate where the library is helping us be expressive, but this will not be an exhaustive explanation of the library, for that please see Jean-Paul's blog.

The application will be written using the Model-View-Presenter pattern and I had two common patterns to choose from; the passive view and the supervising controller.

My personal style is not to have intermediate DTO objects in between the presenter and the view that provides context data between the two, so I will generally be going with the passive view.

There is also the communication mechanism to think about between the view and presenter - we can use events to communicate to the presenter when something happens on the view, or we can communicate directly from the view using presenter methods.

Again, my personal style is to favour the direct communication without the ugly event syntax, but there may be room for hooking up to the existing web forms Init and Load events of the page life cycle automatically so we can remove the need for an Init or Start() method on the presenter that always has to be called. Alternatively I may create a base presenter and view class that handles the initialisation process without a need for it in every concrete view.

Enough preamble, I'm off to write the code.