behavior software development core activities processes requirements design engineering construction testing debugging deployment maintenance paradigms and models agile cleanroom incremental prototyping spiral v model waterfall methodologies and frameworks asd devops dad dsdm fdd iid kanban lean sd less mdd msf psp rad rup safe scrum semat tsp up xp supporting disciplines configuration management documentation software quality assurance sqa project management user experience practices atdd bdd cco ci cd ddd pp standup tdd tools compiler debugger profiler gui designer modeling ide build automation release automation infrastructure as code testing standards and bodies of knowledge babok cmmi ieee standards iso 9001 isoiec standards pmbok swebok itil glossaries artificial intelligence computer science electrical and electronics engineering vte in software engineering behaviordriven development bdd is a software development process that emerged from testdriven development tdd although bdd is principally an idea about how software development should be managed by both business interests and technical insight the practice of bdd does assume the use of specialized software tools to support the development process although these tools are often developed specifically for use in bdd projects they can be seen as specialized forms of the tooling that supports testdriven development the tools serve to add automation to the ubiquitous language that is a central theme of bdd bdd is largely facilitated through the use of a simple domainspecific language dsl using natural language constructs eg englishlike sentences that can express the behavior and the expected outcomes test scripts have long been a popular application of dsls with varying degrees of sophistication bdd is considered an effective technical practice especially when the problem space of the business problem to solve is complex history behaviordriven development is an extension of testdriven development development that makes use of a simple domainspecific scripting language these dsls convert structured natural language statements into executable tests the result is a closer relationship to acceptance criteria for a given function and the tests used to validate that functionality as such it is a natural extension of tdd testing in general bdd focuses on where to start in the process what to test and what not to test how much to test in one go what to call the tests how to understand why a test fails at the heart of bdd is a rethinking of the approach to the unit testing and acceptance testing that naturally arise with these issues for example bdd suggests that unit test names be whole sentences starting with a conditional verb should in english for example and should be written in order of business value acceptance tests should be written using the standard agile framework of a user story as a starting from this point many people developed bdd frameworks over a period of years finally framing it as a communication and collaboration framework for developers qa and nontechnical or business participants in a software project gave the following description of bdd bdd is a secondgeneration outsidein pullbased multiplestakeholder multiplescale highautomation agile methodology it describes a cycle of interactions with welldefined outputs resulting in the delivery of working tested software that matters dan north created a bdd framework jbehave he also worked with david chelimsky aslak hellesy and others to develop rspec and also to write the rspec book behaviour driven development with rspec cucumber and friends the first storybased framework in rspec was later replaced by cucumber mainly developed by aslak hellesy capybara which is a part of the cucumber testing framework is one such webbased test automation software principles of bdd testdriven development is a software development methodology which essentially states that for each unit of software a software developer must define a test set for the unit first make the tests fail then implement the unit finally verify that the implementation of the unit makes the tests succeed this definition is rather nonspecific in that it allows tests in terms of highlevel software requirements lowlevel technical details or anything in between one way of looking at bdd therefore is that it is a continued development of tdd which makes more specific choices than tdd behaviordriven development specifies that tests of any unit of software should be specified in terms of the desired behavior of the unit behavioral specifications following this fundamental choice a second choice made by bdd relates to how the desired behavior should be specified in this area bdd chooses to use a semiformal format for behavioral specification which is borrowed from user story specifications from the field of objectoriented analysis and design the scenario aspect of this format may be regarded as an application of hoare logic to behavioral specification of software units using the domain language of the situation bdd specifies that business analysts and developers should collaborate in this area and should specify behavior in terms of user stories which are each explicitly written down in a dedicated document title the story should have a clear explicit title narrative a short introductory section that specifies who which business or project role is the driver or primary stakeholder of the story the actor who derives business benefit from the story what effect the stakeholder wants the story to have why business value the stakeholder will derive from this effect acceptance criteria or scenarios a description of each specific case of the narrative such a scenario has the following structure it starts by specifying the initial condition that is assumed to be true at the beginning of the scenario this may consist of a single clause or several it then states which event triggers the start of the scenario finally it states the expected outcome in one or more clauses bdd does not have any formal requirements for exactly how these user stories must be written down but it does insist that each team using bdd come up with a simple standardized format for writing down the user stories which includes the elements listed above a very brief example of this format might look like this story returns go to stock as a store owner in order to keep track of stock i want to add items back to stock when theyre returned scenario 1 refunded items should be returned to stock given that a customer previously bought a black sweater from me and i have three black sweaters in stock when they return the black sweater for a refund then i should have four black sweaters in stock scenario 2 replaced items should be returned to stock given that a customer previously bought a blue garment from me and i have two blue garments in stock and three black garments in stock when they return the blue garment for a replacement in black then i should have three blue garments in stock and two black garments in stock the scenarios are ideally phrased declaratively rather than imperatively in the business language with no reference to elements of the ui through which the interactions take place this format is referred to as the gherkin language which has a syntax similar to the above example the term gherkin however is specific to the cucumber jbehave behave and behat software tools specification as a ubiquitous language behaviordriven development borrows the concept of the ubiquitous language from domain driven design a common risk with software development includes communication breakdowns between developers and business stakeholders this model is also the basis for the different bddsupporting software tools that are available the example given above establishes a user story for a software system under development this user story identifies a stakeholder a business effect and a business value it also describes several scenarios each with a precondition trigger and expected outcome each of these parts is exactly identified by the more formal part of the language the term given might be considered a keyword for example and may therefore be processed in some way by a tool that understands the formal parts of the ubiquitous language most bdd applications use textbased dsls and specification approaches however graphical modeling of integration scenarios has also been applied successfully in practice eg for testing purposes specialized tooling support much like testdriven design practice behaviordriven development assumes the use of specialized support tooling in a project in as much as bdd is in many respects a more specific version of tdd the tooling for bdd is similar to that for tdd but makes more demands on the developer than basic tdd tooling tooling principles in principle a bdd support tool is a testing framework for software much like the tools that support tdd however where tdd tools tend to be quite freeformat in what is allowed for specifying tests bdd tools are linked to the definition of the ubiquitous language discussed earlier as discussed the ubiquitous language allows business analysts to write down behavioral requirements in a way that will also be understood by developers the principle of bdd support tooling is to make these same requirements documents directly executable as a collection of tests if this cannot be achieved because of reasons related to the technical tool that enables the execution of the specifications then either the style of writing the behavioral requirements must be altered or the tool must be changed the exact implementation of behavioral requirements varies per tool but agile practice has come up with the following general process the tooling reads a specification document the tooling directly understands completely formal parts of the ubiquitous language such as the given keyword in the example above based on this the tool breaks each scenario up into meaningful clauses each individual clause in a scenario is transformed into some sort of parameter for a test for the user story this part requires projectspecific work by the software developers the framework then executes the test for each scenario with the parameters from that scenario dan north has developed a number of frameworks that support bdd including jbehave and rbehave whose operation is based on the template that he suggested for recording user stories tooling examples there are several different examples of bdd software tools in use in projects today for different platforms and programming languages possibly the most wellknown is jbehave which was developed by dan north the following is an example taken from that project consider an implementation of the game of life a domain expert or business analyst might want to specify what should happen when someone is setting up a starting configuration of the game grid to do this he might want to give an example of a number of steps taken by a person who is toggling cells skipping over the narrative part he might do this by writing up the following scenario into a plain text document which is the type of input document that jbehave reads given a 5 by 5 game when i toggle the cell at 3 2 then the grid should look like x when i toggle the cell at 3 1 then the grid should look like x x when i toggle the cell at 3 2 then the grid should look like x the bold print is not part of the input it is included here to show which words are recognized as formal language jbehave recognizes the terms given as a precondition which defines the start of a scenario when as an event trigger and then as a postcondition which must be verified as the outcome of the action that follows the trigger based on this jbehave is capable of reading the text file containing the scenario and parsing it into clauses a setup clause and then three event triggers with verifiable conditions jbehave then takes these clauses and passes them on to code that is capable of setting a test responding to the event triggers and verifying the outcome this code must be written by the developers in the project team in java because that is the platform jbehave is based on in this case the code might look like this private game game private stringrenderer renderer givena width by height game public void thegameisrunningint width int height game new gamewidth height renderer new stringrenderer gamesetobserverrenderer wheni toggle the cell at column row public void itogglethecellatint column int row gametogglecellatcolumn row thenthe grid should look like grid public void thegridshouldlooklikestring grid assertthatrendererasstring equaltogrid the code has a method for every type of clause in a scenario jbehave will identify which method goes with which clause through the use of annotations and will call each method in order while running through the scenario the text in each clause in the scenario is expected to match the template text given in the code for that clause for example a given in a scenario is expected to be followed by a clause of the form a x by y game jbehave supports the matching of clauses to templates and has builtin support for picking terms out of the template and passing them to methods in the test code as parameters the test code provides an implementation for each clause type in a scenario which interacts with the code that is being tested and performs a test based on the scenario in this case the thegameisrunning method reacts to a given clause by setting up the initial game grid the itogglethecellat method reacts to a when clause by firing off the toggle event described in the clause the thegridshouldlooklike method reacts to a then clause by comparing the state of the game grid to the expected state from the scenario the primary function of this code is to be a bridge between a text file with a story and the code being tested note that the test code has access to the code being tested in this case an instance of game and is very simple in nature the test code has to be simple otherwise a developer would end up having to write tests for his tests finally in order to run the tests jbehave requires some plumbing code that identifies the text files which contain scenarios and which inject dependencies like instances of game into the test code this plumbing code is not illustrated here since it is a technical requirement of jbehave and does not relate directly to the principle of bddstyle testing story versus specification a separate subcategory of behaviordriven development is formed by tools that use specifications as an input language rather than user stories an example of this style is the rspec tool that was also originally developed by dan north specification tools dont use user stories as an input format for test scenarios but rather use functional specifications for units that are being tested these specifications often have a more technical nature than user stories and are usually less convenient for communication with business personnel than are user stories an example of a specification for a stack might look like this specification stack when a new stack is created then it is empty when an element is added to the stack then that element is at the top of the stack when a stack has n elements and element e is on top of the stack then a pop operation returns e and the new size of the stack is n1 such a specification may exactly specify the behavior of the component being tested but is less meaningful to a business user as a result specificationbased testing is seen in bdd practice as a complement to storybased testing and operates at a lower level specification testing is often seen as a replacement for freeformat unit testing specification testing tools like rspec and jdave are somewhat different in nature from tools like jbehave since they are seen as alternatives to basic unit testing tools like junit these tools tend to favor forgoing the separation of story and testing code and prefer embedding the specification directly in the test code instead for example an rspec test for a hashtable might look like this describe hash do lethash hash it expecthashnewto eq it hashes the correct information in a key do expecthashto eqworld end it includes key do hashkeysincludehelloshould be true end end this example shows a specification in readable language embedded in executable code in this case a choice of the tool is to formalize the specification language into the language of the test code by adding methods named it and should also there is the concept of a specification precondition the before section establishes the preconditions that the specification is based on the result of test will be hash should eq includes key hashes the correct information in a key behat php framework yatspec java framework replaces concordion concordion java framework cucumber ruby framework gauge software jasmine javascript testing framework squish gui tester bdd gui testing tool for javascript python perl ruby and tcl use case 