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 NameState Interaction Outcome
The user clicks the save button 
Have permissionAttempts to saveThe 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 permissionsAttempts to get informationUser 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