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.
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.
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
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.
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.
|Have permission||Attempts to save|
|Doesnt have full permission||Attempts to save||Error|
|Have permission||Attempts to get information|
|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|
|Doesnt have permission||Attempts to get information||Error, redirects to homepage|
|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