Behavior-Driven Development

alternative to Test Driven Development?

Behavior-driven development (BDD) is an agile software development method centered around collaboration between business and IT professionals that have a stake in finding a solution for a complex problem. The core objective is to achieve a shared understanding of the problem.[1] BDD involves use of a domain-specific language (DSL) using natural-language constructs (e.g., English-like sentences) that can express the behavior and the expected outcomes.[2] BDD encourages collaboration among developers, quality assurance experts, and customer representatives in a software project.[3][4] It encourages teams to use conversation and concrete examples to formalize a shared understanding of how the application should behave.[5] BDD is considered an effective practice especially when the problem space is complex. https://en.wikipedia.org/wiki/Behavior-driven_development

• BDD suggests that business analysts and software developers should collaborate in this area and should specify behavior in terms of user stories, which are each explicitly documented. Each user story should, to some extent, follow the structure:[10]
• Title: An explicit title.
• Narrative: A short introductory section with the following structure:
  • As a: the person or role who will benefit from the feature;
  • I want: the feature;
  • so that: the benefit or value of the feature.
• Acceptance criteria: A description of each specific scenario of the narrative with the following structure: (acceptance test)
  • Given: the initial context at the beginning of the scenario, in one or more clauses;
  • When: the event that triggers the scenario;
  • Then: the expected outcome, in one or more clauses. (Given/When/Then)
• BDD does not require how this information is formatted, but it does suggest that a team should decide on a relatively simple, standardized format with the above elements.[10] It also suggests that the scenarios should be phrased declaratively rather than imperatively — in the business language, with no reference to elements of the UI through which the interactions take place.[13] This format is referred to in Cucumber as the Gherkin language.
• BDD borrows the concept of the ubiquitous language (shared language) from domain driven design.[10][9] A ubiquitous language is a (semi-)formal language that is shared by all members of a software development team — both software developers and non-technical personnel.[14] The language in question is both used and developed by all team members as a common means of discussing the domain of the software in question.[14] In this way BDD becomes a vehicle for communication between all the different roles in a software project. Mar'2011: Jeffrey P Shell notes that DHH isn't a big fan of the Ruby On Rails frameworks that support this: I respect the guys behind it and I'm all for experimentation, but the proliferation of rSpec and Cucumber makes me sad. Shell agrees: I'm glad that these kinds of tests have never really caught fire in the Python world. There are implementations of the rSpec and Cucumber ideas, but they don't seem to be as fully embraced. In my opinion, the dark side of testing in the Python world is the abuse of DocTests, thinking that they make both good test cases and good documentation, when in fact they're neither... As David points out, the complexity going on behind the scenes to make the tests just seems silly. Granted, 'Unit Tests' aren't always that easy to read, but they offer a finer example of API interactions. And if you want clarity, just add some comments. Take a cucumber-esque line like "verify that the file is encoded in UTF-8" and "now the file is encoded as latin-1" and put them as comments above the test/assert/verify statements that prove that line.