What's Behaviour-Driven Development ?
Behaviour-Driven Development (BDD) is an evolution in the thinking behind TestDrivenDevelopment and AcceptanceTestDrivenPlanning. It brings together strands from TestDrivenDevelopment and DomainDrivenDesign into an integrated whole, making the relationship between these two powerful approaches to software development more evident.
It aims to help focus development on the delivery of prioritised, verifiable business value by providing a common vocabulary (also referred to as a UbiquitousLanguage) that spans the divide between Business and Technology. It presents a framework of activity based on three core principles:
- Business and Technology should refer to the same system in the same way - ItsAllBehaviour
- Any system should have an identified, verifiable value to the business - WheresTheBusinessValue
- Up-front analysis, design and planning all have a diminishing return - EnoughIsEnough
BDD relies on the use of a very specific (and small) vocabulary to minimise miscommunication and to ensure that everyone – the business, developers, testers, analysts and managers – are not only on the same page but using the same words.
For people familiar with the concept of DomainDrivenDesign, you could consider BDD to be a UbiquitousLanguage for software development. It must be stressed that BDD is a rephrasing of existing good practice, it is not a radically new departure. Its aim is to bring together existing, well-established techniques under a common banner and with a consistent and unambiguous terminology. BDD is very much focused on “Getting the words right” and this focus is intended to produce a vocabulary that is accurate, accessible, descriptive and consistent.
What's Problem ?
Test Driven Development (TDD) has established itself as a useful--and at its best, profound--improvement in the software development process. It delivers a variety of benefits to its practitioners; some of them are related to testing, but the most important benefits are not.
Experienced practitioners, particularly those that have been involved in helping other developers learn the practice, note a life-cycle to TDD's learning and adoption:
- The developer starts writing unit tests around their code using a test framework like JUnit or NUnit.
- As the body of tests increases the developer begins to enjoy a strongly increased sense of confidence in their work.
- At some point the developer has the insight (or is shown) that writing the tests before writing the code, helps them to focus on writing only the code that they need.
- The developer also notices that when they return to some code that they haven't seen for a while, the tests serve to document how the code works.
- A point of revelation occurs when the developer realises that writing tests in this way helps them to “discover” the API to their code. TDD has now become a design process.
- Expertise in TDD begins to dawn at the point where the developer realizes that TDD is about defining behaviour rather than testing.
- Behaviour is about the interactions between components of the system and so the use of mocking is fundamental to advanced TDD.
We have observed this progression in many developers, but unfortunately while most, with a little help, find their way to step 4, many miss the big wins found at steps 5, 6 and 7.
We started wondering why this was, and wondering what we could do to help people get to the good stuff more quickly. Looking closely at this evolution in understanding, while step 1 may be considered to be related to testing, the rest really are not. For the remainder of the steps in this process, the test aspect is very much a secondary concern.
The issue at the heart of this learning process is the behaviour of the system. Developers gain confidence in the systems they build when the behaviour of that system is confirmed.
The issue at the heart of this learning process is the behaviour of the system. Developers gain confidence in the systems they build when the behaviour of that system is confirmed.
By writing tests in advance of code, the developer defines the behavioural intent of the system that they are developing. Tests that document the behavioural intent of the system are most valuable as documentation of that system. By specifying the behaviour of the code in tests, developers are able to best consider the interface from the perspective of the consumer of the service rather than as the producer – thinking more abstractly about the nature of the solution and so hiding technical detail.
This focus on behaviour ahead of testing is a focus on the real value in TDD, and in our experience is the mark of the genuinely experienced TDD practitioner.
It is not too surprising that it takes apprentice TDD practitioners a while to realize that TDD is not about testing when all of the nomenclature surrounding it is described in terms of testing.
and what's solution ?
The aim of Behaviour Driven Development (BDD) is to address this shortcoming. By using terminology focused on the behavioural aspects of the system rather than testing, BDD attempts to help direct developers towards a focus on the real value to be found in TDD at its most successful.
BDD aims to bridge the gap between the differing views of computer systems held by Business users and Technologists. It is deeply rooted in the success of TDD and is influenced by ideas like Domain Driven Design.
Its focus is on minimizing the hurdles between specification, design, implementation and confirmation of the behaviour of a system. Thus enabling the incremental delivery of business systems, and in particular in allowing teams new to agile development to quickly get up to speed using these extremely productive techniques.
Its focus is on minimizing the hurdles between specification, design, implementation and confirmation of the behaviour of a system. Thus enabling the incremental delivery of business systems, and in particular in allowing teams new to agile development to quickly get up to speed using these extremely productive techniques.
Getting the words right
Behaviour Driven Development (BDD) grew out of a thought experiment based on Neuro Linguistic Programming (NLP) techniques. The idea is that the words you use influence the way you think about something.
As an example, when I was first getting to grips with TDD, I was pairing with an experienced agile coach, writing little test methods, then writing the code, and generally feeling good about life. Then I went ahead and wrote some code without a test. The coach, JR, asked me why I'd written the code. I answered: "we'll need it in a minute", to which JR replied "yes, we might". By using the word "might", he introduced the possibility that we might not. As it turned out, we didn't. - DanNorth
A coach introducing Test Driven Development (TDD) to sceptical (i.e. most) developers invariably runs into a familiar set of objections.
From programmers:
- Why do I need to write tests? That's what testers do.
- Writing all these tests slows me down, it's a waste of time.
- I'm a good programmer! I don't need to write tests to prove my code works
And from testers:
- Why are you getting programmers to write tests? We all know they can't – that's why you need testers.
- Are you trying to take our jobs away?
- You obviously don't understand testing or you wouldn't be asking programmers to write tests!
This last comment is particularly ironic. In fact, the testers take on a central and very important role in BDD.
The behaviour-centric vocabulary helps us to avoid these common misunderstandings and focus on BDD as a design and delivery process.
Concentrating on finding the right words led us to think about the process differently, for example, the fact that the words we use in BDD are very much focussed on the behaviour of the system led us to better understand the very close relationship between the stories we use to specify behaviour and the specifications we implement in BDD in place of tests. It also helped us gain further insight into some of the failure modes we have experienced in TDD projects.
The BDD Process Model
A SubjectMatterExpert (typically a business user) works with a BusinessAnalyst to identify a business requirement. This is expressed as a story using the following template:
As a Role
I request a Feature
To gain a Benefit
As a Role
I request a Feature
To gain a Benefit
The speaker, who holds the Role, is the person who will gain the Benefit from the requested Feature.
This can also be paraphrased variously as ...
1. I want to achieve a specific Goal, and as a Role I should be able to accomplish this by performing Functionality.
2. A Role invokes Feature to cause a Benefit
BDD Example with Groovy
Easyb is a behavior driven development framework for the Java platform. By using a specification based Domain Specific Language, easyb aims to enable executable, yet readable documentation.
Example Stories with easyb
Example Specification with easyb
BDD On Java using JBehave
JBehave is a framework for Behaviour-Driven Development Behaviour-driven development (BDD) is an evolution of test-driven development (TDD) and acceptance-test driven design, and is intended to make these practices more accessible and intuitive to newcomers and experts alike.
It shifts the vocabulary from being test-based to behaviour-based, and positions itself as a design philosophy.
1. I want to achieve a specific Goal, and as a Role I should be able to accomplish this by performing Functionality.
2. A Role invokes Feature to cause a Benefit
BDD Example with Groovy
Easyb is a behavior driven development framework for the Java platform. By using a specification based Domain Specific Language, easyb aims to enable executable, yet readable documentation.
Example Stories with easyb
Example Specification with easyb
BDD On Java using JBehave
JBehave is a framework for Behaviour-Driven Development Behaviour-driven development (BDD) is an evolution of test-driven development (TDD) and acceptance-test driven design, and is intended to make these practices more accessible and intuitive to newcomers and experts alike.
It shifts the vocabulary from being test-based to behaviour-based, and positions itself as a design philosophy.
and here is another example with java using JBehave.
Source:BDD - http://behaviour-driven.org/Easyb - http://easyb.org/JBehave -http://jbehave.org/
Dear AliReza
ReplyDeleteAt first we have a question about Groovy :
Groovy What benefits to offer over the use of Java syntax than a more complicated?
and I think the best answer is this :
Dynamic typing. For people coming from Perl, Python, Ruby, Java, etc type of system is a straitjacket that serves no purpose but to enter the road. Other good things are regular expressions as first class citizens and closures. For example, how much more you need the Java code to read each file passed on the command line and print only the lines containing the string "new".
for (file args) (
new file (file). eachLine (line ->
if (line = ~ / new /) (
println line
)
)
)
Note that the program is full, a fragment of a larger program.
The Groovy language has a wide range of features that are sadly lacking in Java. These include:
* Properties
* Closure
* Metaprogramming
Multi-line Strings
* String interpolation
* Mixins / Categories
* Named arguments
* The default arguments
* Collection Literals
* Operator overloading
* GPath expressions
* Additional operators, for example, '? ". (A secure version of the null operator." Java ")
And many more that I can not think of the time. The net result is that for a given task in the Groovy code usually takes much less than in Java. Much of the code that you do not have to write using Groovy could be considered as 'repetitive'.
Not only the language of the extra features that Groovy offers, is also additional methods Groovy adds to the more commonly used JDK classes. These allow one to make the most of the Groovy language features (closures, in particular) when working with the collection of Java classes.
The dynamic nature of Groovy also reduces the amount of code, despite the advantages and disadvantages of static and dynamic types is a debate for another day.
Best Regards
MK
That's great, thanks for your comment, as exactly you said it's very exiting language, now we have best power from java VM and dynamic language all together.
ReplyDeleteAdditionally it has very potential for agile development philosophy, and until now it has very plug-in and even frameworks for developing desktop and web application easily with enterprise qualities.
I suggest you to search about Grails and Griffon in this regards. there are very exciting framework on Groovy language ;)