Making beautiful business applications

Behaviour Driven Development

I recently went to the developer usergroup at Microsoft in Bryanston, Johannesburg. Joshua Lewis (twitter account here, blog here). He was talking about a model in which we think about how to improve a system that is working. Hold on, if the thing is working, why do we need to improve it?

I personally see how behaviour driven development can help in making developers not do unecessary things the client or business do not require.

Defining the outcomes

The question is actually, is it working as expected?

The main question on this is: What do we expect?

What is it suppose to do?

Sometimes nobody actually knows how the thing should work in the first place.

It becomes important in pinning down what exactly this is. Once you know what the system should be doing, we can look at outcomes – what we expect.

An example:

I am currently busy with a a piece of code that needs the user to type in information. This is then saved and used as a contract of sorts between the parties involved.

I need to consider the following outcomes:

  • The user’s information is saved
  • The user is able to retrieve the information

Defining the process

The system can be seen as something like this:

Interaction > System > desired output

Meaning: I do something, the system does something, then i get a result.

An example:

Taking the above example a bit further:

  • The user clicks the save button > insert magic here > The user’s information is saved
  • The user clicks to see an existing contract > insert magic here >  The user is able to retrieve the information

Other factors

But it is never this simple, right? Sometimes we have other factors that could play a role. One of these is the state of the software. This means that the system might react differently depending on what it is busy with in some way.

An example:

A great example of this would be logged in permissions – someone is only able to see/edit/change/delete certain things at certain times. Yet this does complicate the scenario a bit, but following this model, we should have a good overview of all the things that our system needs to cover.

 

Scenario Name State Interaction Outcome
The user clicks the save button  Have permission Attempts to save The user’s information is saved
The user clicks the save button  Doesnt have full permission Attempts to save Error
The user clicks to see an existing contrac Have permission Attempts to get information
The user clicks to see an existing contract Have limited permissions Attempts to get information User can see only certain areas that they have access to – these needs to be specified and used as new inputs here
The user clicks to see an existing contract Doesnt have permission Attempts to get information Error, redirects to homepage
The user clicks to see an existing contract Have full permission Attempts to get information Sees everything

 

 

The user sees only things he has access to

The user logs in and goes to the page to setup the contract > insert magic here > The user sees only things he has access to

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *