Behavior-driven development introduction

What is the behavior-driven development approach. It's just another approach to build automated tests, like decomposition, keyword-driven, data-driven, object-based. Key feature of this approach is that each action is represented with some specific sentence describing actions to be done. And it's usually natural-language instruction. So, we actually describe some behaviour of AUT after some actions with it. So, at the highest level test is represented something like that:

Open application
Enter "Test" text into "Search" field
Click on Go button

These are high-level instructions. Overall engine just parses this text and each line is set to correspondence to some function written in programming language.

Looks similar to keyword-driven testing. Key difference is that keyword-driven engine operates with structured data like:

• operation to do
  
• operation parameters
  

And these items are represented as separate entities (e.g. separate columns in tests table). Behavior-driven development instructions do not have such strict distributions. Each instruction is some command but parameters can be part of instruction. For instance, from the previous example we can take an instruction like:

Enter "Test" text into "Search" field

and pay additional attention to fields highlighted with bold. First field reflects the text to enter and second field is some kind of field name. In general it's primitive operation of text entry and it can be applicable to many different fields. So, words "Test" and "Search" can vary but operation should be the same. At the engine level we associate some function/method with some regular expression. Text parser just extracts lines and finds appropriate regular expression and calls associated method. This is brief description of the approach itself. With such association type we can create quite flexible text instructions which look like natural language instructions. Well, the behaviour-driven development approach looks one of the most advanced and high-level automated testing approach we have at the moment. The key thing is that it's balanced between technical complexity and simplicity to use. Of course, there're more complex solutions like model-based development but the last one is too complex from technical point of view as well as it requires strict diagram modelling rules being keep by all team members (which is hardly doable). If we compare it with keyword-driven approach we can see that even taking into account that these approaches are similar from technical point of view the keyword-driven tests still have some strict structure representation. Behavior-driven instructions are actually simple plain text designed the way we need. Solutions supporting BDD:

• JBehave for Java
  
• JBehave for .NET
  
• Cucumber for Ruby
  

Main advantages:

• Easy to read and understand what actually test does.
  
• Having some set of instructions we can build our tests just like we can build wall with bricks. So, at the tests instructions level we don't need any special programming skills.
  
• As a keyword-driven approach BDD is easily portable into any programming language. It's possible because test instructions are separated from actual actions implementations as a separate layer. So in case of language changes the instructions level is still left unchanged
  

Well, there're a lot of good things in it but gaps can be quite essential too. Just some of them:

• As keyword-driven approach the BDD is hard to support for large scale solutions when there're a lot of instructions and there's probability that some instructions refer to the similar actions. Also, when the number of instructions is huge it's hard to find required one. So, all regular expressions and instruction implementations should be placed in some ordered structure
  
• Either quite strict syntax considerations or flexible and complex regular expressions are needed to cover each particular variation of natural language instruction. In some cases we may put some text into quotes and in some cases we may not but both cases should be handled in the same way. The same thing is when we vary upper and lower case.
  
• When we associate some function/method with some particular text instruction we should have some global data storage to transfer data between each function. One of thside effects is that some test instructions are actually dependent on other instructions and in some cases it isn't clear.
  
• Documentation is difficult as BDD approach isn't language-specific solution. And in some cases it require proper and detailed description
  

So, it's up to you whether advantages are more serious than gaps or not. The only thing we should keep in mind is that we always should pay attention to the overall solution design and architecture. Without it even simple solution will bring troubles.