What would be the additional benefits of wrapping a bdd(behavior development design) framework around a proprietary test tool besides the natural language aspect of the test steps?
Any suggestions for tools that would ease such a bdd integration with test tool/tools?
The main benefit is tests that are written in the users language using business domain terms.
This helps to bring both the developers and users together for a better understanding and implementation of applications.
For some aspects, programmers will appreciate product owners being very specific and writing down specifications and requirements in a logical fashion. For other aspects product owners will appreciate being able to understand the functionality that has been implemented based on the tests they they can read in plain English. In other cases programmers are made more aware of subtle real world factors that can dramatically affect design and implementation.
One example of this framework in action is Cucumber which is commmony a wrapper around RSpec but can and has also been used with many other development frameworks and languages.
I feel some of the additional benefits are:
Isolation of test harness from the testing tool. By this I mean the only point the test tool is invoked is when performing actions on the web browser.
Natural pagination by excepting the previous step to put into appropriate page context for the current step to act on.
Better reporting by means of natural english sentences.
Hierarchical/structured approach to testing allows for better debugging since there is a narrower view. So a step failing could be tracked back to an action as opposed to navigating through an entire script of actions.
In regards to a tool, I have written the following which allows cucumber-js to integrate with any testing tool by means of a driver: wrap-bdd on a nodejs platform. Only drivers so far implemented as an example are for test complete and test execute tool.
https://github.com/vsashidh/generator-wrap-bdd : installer
Behaviors Become Defined
If everyone is on board with the process instead of a list of requirements, everyone gets a list of Behaviors which then define the requirements. As the process is used more, and discussions are had these behaviors become more thorough and the requirements become clearly defined from them.
Test cases are easier
When BDD frameworks are used correctly, test cases are easier for everyone. By seeing in a human readable format what the test case was doing when it failed, you can then be able to determine further actions and discovery processes to determine any other issues.
Following Patterns
Software Development tends to have patterns of defects. If your BDD framework has historical data, it will allow you to follow these patterns. As an example, one of the common areas for issues that I have seen is with roles and permissions. Since I know this is a common area for issues instead of waiting for development to finish, getting the code into QA, finding issues with it and then sending back to Dev I am able to ensure that part of the BDD includes the roles and permissions up front, ensuring that my developers understand exactly what they are attempting to accomplish.
Think first, Code later
All *DD follows this basic principle. Writing code is a privilege, one that is earned by determining the problems you are going to face up front. While this doesn't result in perfect code, it does help to reduce mistakes and makes everyone's life better.
I am using SpecFlow with XUnit and c#, and I find that well-written SpecFlow scenario steps keep the step definition code's purpose very clear. It effectively documents and comments the code, and encourages single responsibility and reuse.
Two biggest advantages of BDD are
Added benefit is that the whole team is focused on the biggest value for the end-user: behavior, since ultimately users care how the product behaves.
