A Bit of Up Front Planning

They do say that in Agile there is no up front planning, well I like to do a little bit, just so I know the direction I should set off, and the bit of space it gives allows me to think about the problem, for me a problem always sounds difficult if not insurmountable, before a bit of thought.

In the last blog post I spoke about how I approach test first development in a way that improves the ability to refractor code, reducing the requirement for mocking between layers of an application by only mocking at the application boundaries.  I thought it would be good to build an application in this way, and show how the tests allow for refactoring and changes over time.

I need a project to work on that can start very simply and grow but does not have large visual requirements, so I chose the typical basket component as my application.  Think of the checkout basket API as a single service of a larger shopping system, each part communicating over http using a JSON format.  In there complete system there would be a web front end or mobile application, other services that provide search, and product listing and our checkout basket, which will provide the all the basket, order calculations ready for the customer to checkout through a payment system. 

It may be our basket system will call other related systems within the system a product service comes to mind as a possibility, but this will come out in requirements later in development.

To this end I have created a git repository where all the source will be located, the master will contain the release version, and a branch will exist for each stage of development.

So now some hammock driven development, we are going to build the basket using a service in C#, so other than C# what else will we use, I am going to need some form of Web API framework, I thought about using the build in MVC, or maybe the Web API but for what I want it seams a bit heavy and I want a test framework that is easy to use and fits in with the behaviour style tests I am going to write, I am thinking of using NancyFx for the basic API, it supports tests and has little setup requirements and will support the JSON format easily.  As for the test framework, that will probably be NUnit or something based on it as this is the simplest test framework and its well known within the C# community.

The basket service is going to have some functionality so that the basket can be created, have items added to it, items removed from it and to be able to be returned to a caller with all the items that it contains listed.  There is also a probably that there will be some totalling of items and application of discounts, and other requirements I haven’t even thought about yet.

Now we have the problem and where it fits into the application, some thoughts about the sort of frameworks and tooling we want to use, nothing concrete at this point but some things to ponder before diving into the computer.

I have setup a basic project, the idea is that each stage of the development will be a feature branch that is merged back into the trunk, so each stage of development can be seen, along with all the mistakes and failures that typically haunt a project along with all the successes!

I think a good starting point will be the basket creation,  in a REST ish style thinking about the basket as a resource, I think our caller will make a call to the checkout basket API to “get” a basket without an id will be the return a new basket, and with an id will return a existing basket.

/basket
or
/basket/{basket id}

The first tests I will write then are going to be to do with creating a basket, calling basket without an id, this will return the JSON representation of a basket, something like

{ “Id” : “a unique basket id” }

This will be expanded as time goes on, but currently we just need a unique id, enough thinking lets write our first failing test.

So getting to the code I have created a branch called “createbasket”, I have two tests in mind, the first will be that we have a id and the second is that the basket is empty, I am planning on returning the basket as JSON from the call. at this point the project looks like this.create basket solution start We now need to add a couple of NuGet packages which will assist in our development, to the “CreateBasketAPI” project I added the Nancy package and to the “CheckoutBasket.Specifications” project I added the NUnit package, the Nancy.Testing package and the Shouldly package. With these installed we are ready to start.

I like to use the Given – When syntax for my tests, to this end I create a small base class which my tests can inherit from to provide simple hooks for this syntax.

namespace CheckoutBasket.Specifications
{
[TestFixture]
public abstract class BddBase
{
[SetUp]
public void Setup()
{
Given();

When();
}

protected abstract void Given();

protected abstract void When();
}
}

With this in place I am ready to write the first test of the project.

Advertisements

About Duncan Butler

Trying to be a very agile software developer, working in C# with Specflow, Nunit and Machine Specifications, and in the evening having fun with Ruby and Rails
This entry was posted in Programming. Bookmark the permalink.

One Response to A Bit of Up Front Planning

  1. Pingback: The First Test | The Butler Did It

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s