CSC/ECE 517 Fall 2014/ch1b 29 ry: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
(Hyperlinks and references)
(Formatting)
 
(40 intermediate revisions by 2 users not shown)
Line 1: Line 1:
==Behavior-driven development using JBehave==
==Behavior-Driven Development using JBehave ==
JBehave is an [http://en.wikipedia.org/wiki/Open_source open-source], Java-based [http://behaviour-driven.org/ Behavior-driven development] (BDD) framework. It was originally developed by Dan North in 2003 to improve upon the underlying principles of [http://agiledata.org/essays/tdd.html Test-driven development].<ref>http://www.slideshare.net/shadrik/bdd-with-java-8323915</ref>  
JBehave is an [http://en.wikipedia.org/wiki/Open_source open-source], Java-based [http://behaviour-driven.org/ Behavior-driven development] (BDD) framework. It was originally developed by Dan North in 2003 to improve upon the underlying principles of [http://agiledata.org/essays/tdd.html Test-driven development].<ref>Vasilev, Nikolay. [http://www.slideshare.net/shadrik/bdd-with-java-8323915 "BDD with JBehave and Selenium"], 16 June 2011. Retrieved on 13 October 2014.</ref>
{| align=right style="border: 1px solid gray;" class="wikitable"
|+ JBehave
|-
| colspan="2" | [[file:Jbehave-logo.png]]
|-
| Developer || [http://dannorth.net/ Dan North]
|-
| Initial release || 2003
|-
| Stable Release || [http://jbehave.org/reference/stable/release-notes.html 3.9.4] - Aug. 24, 2014
|-
| Written in || [http://en.wikipedia.org/wiki/Java_%28programming_language%29 Java]
|-
| Type || [[CSC/ECE_517_Fall_2012/ch1b_1w69_mv|BDD]] Framework
|-
| License || [http://en.wikipedia.org/wiki/BSD_licenses BSD]-style license<ref>[http://jbehave.org/reference/stable/license.html "JBehave License"]. Retrieved on 13 October 2014.</ref>
|-
| colspan="2" align="center" style="font-size: 125%;"| [http://jbehave.org/ jbehave.org]
|}


[[https://docs.google.com/document/d/1--CEtBpSUACsjSSXtDB5bNIOBzHoMJPr8W0DSqasO_4 Write-up 1b topics]]


__TOC__
__TOC__




==Background: BDD as an evolution of TDD==
==Background: Behavior-Driven Development as an evolution of Test-Driven Development==
 
Behavior-Driven Development was conceived as an improvement to the thought processes behind Test-Driven Development (TDD) and [http://testdrivendeveloper.com/2008/04/02/AcceptanceTestDrivenDevelopmentExplained.aspx Acceptance Test-Driven Planning].<ref>[http://behaviour-driven.org/ "The BDD Wiki"]. Retrieved on 13 October 2014.</ref>
Behavior-Driven Development was conceived as an improvement to the thought processes behind Test-Driven Development (TDD) and [http://testdrivendeveloper.com/2008/04/02/AcceptanceTestDrivenDevelopmentExplained.aspx Acceptance Test-Driven Planning].<ref>http://behaviour-driven.org/</ref>
 
===TDD===
[[File:TestDrivenDevelopment.png|frame|300px|The Test-driven development software development cycle]]
Test-driven development, which is often associated with [http://www.extremeprogramming.org/ Extreme Programming], is a software development technique which combines [http://tutorials.jenkov.com/java-unit-testing/test-first-development.html test-first development] and [http://c2.com/cgi/wiki?WhatIsRefactoring Refactoring]. TDD can be described at a high level as a process that iteratively follows the steps below:


[[File:TestDrivenDevelopment.png|frame|300px|The Test-driven development software development cycle<ref>Wikipedia. [http://en.wikipedia.org/wiki/File:Test-driven_development.PNG "A quick overview of the Test-driven development lifecycle"], 12 July 2009. Retrieved on 13 October 2014.</ref>]]
===Test-Driven Development===
Test-driven development, which is often associated with [[CSC/ECE_517_Fall_2011/ch5_6d_ny#Extreme_Programming|Extreme Programming]], is a software development technique which combines [http://tutorials.jenkov.com/java-unit-testing/test-first-development.html test-first development] and [http://c2.com/cgi/wiki?WhatIsRefactoring Refactoring]. TDD can be described at a high level as a process that iteratively follows the steps below:


#Add a test that tests for a required functionality.
#Add a test that tests for a required functionality.
Line 21: Line 40:




At each step along the process for TDD, the developer has to ensure that the new code which has been added does not affect previously written functionality, i.e. all tests written up to that point have to be re-run to ensure that everything is working as expected. TDD offers benefits such as: <ref>http://www.base36.com/2012/07/benefits-of-test-driven-development/</ref>
At each step along the process for TDD, the developer has to ensure that the new code which has been added does not affect previously written functionality, i.e. all tests written up to that point have to be re-run to ensure that everything is working as expected. TDD offers benefits such as: <ref>Base 36. [http://www.base36.com/2012/07/benefits-of-test-driven-development/ "Benefits of test-driven development"], 13 July 2012. Retrieved on 13 October 2014.</ref>
 


*Maintainable, flexible and easily extensible code.
*Maintainable, flexible and easily extensible code.
Line 31: Line 49:




===BDD and JBehave===
===Behavior-Driven Development and JBehave===
 
Behavior-Driven Development is a development paradigm first proposed by Dan North, which aims to make development practices more accessible and intuitive to newcomers and experts alike by shifting the vocabulary from being test-based to behavior-based. It emphasizes communication and automation as equal goals.<ref>http://jbehave.org/introduction.html</ref> In essence, BDD Tests focus more on the features, as opposed to the actual results of the tests. Consequently, BDD helps to design the software, not just test it.<ref>https://joshldavis.com/2013/05/27/difference-between-tdd-and-bdd/</ref>


BDD aims to bridge the gap between the differing views of computer systems held by business users and technologists by using terminology focused on the behavioral aspects of the system rather than testing. Its focus is on minimizing the hurdles between specification, design, implementation and confirmation of the behavior 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 extremely productive techniques.<ref>http://behaviour-driven.org/Introduction</ref>
Behavior-Driven Development is a development paradigm first proposed by Dan North, which aims to make development practices more accessible and intuitive to newcomers and experts alike by shifting the vocabulary from being test-based to behavior-based. It emphasizes communication and automation as equal goals.<ref>[http://jbehave.org/introduction.html Introduction to BDD and JBehave]. Retrieved on 13 October 2014.</ref> In essence, BDD tests focus more on the features, as opposed to the actual results of the tests. Consequently, BDD helps to design the software, not just test it.<ref name="diff">Davis, Josh L. [https://joshldavis.com/2013/05/27/difference-between-tdd-and-bdd/ "Difference between TDD and BDD"], 27 May 2013. Retrieved on 13 October 2014.</ref>


In the words of Dan North, the creator of BDD and JBehave:<ref>http://dannorth.net/introducing-bdd/</ref>
BDD aims to bridge the gap between the differing views of computer systems held by business users and technologists by using terminology focused on the behavioral aspects of the system rather than testing. Its focus is on minimizing the hurdles between specification, design, implementation and confirmation of the behavior 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 extremely productive techniques.<ref>[http://behaviour-driven.org/Introduction "BDD - Introduction (The BDD Wiki)"]. Retrieved on 13 October 2014.</ref>


In the words of Dan North, the creator of BDD and JBehave:<ref name = "dan">North, Dan. [http://dannorth.net/introducing-bdd/ "Introducing BDD"], March 2006. Retrieved on 13 October 2014.</ref>


<blockquote style="text-indent:2em;"><p>
<blockquote style="text-indent:2em;"><p>
Line 51: Line 68:




Towards the end of 2003, North, who had begun promoting BDD as a software development methodology, starting working on a Java framework called JBehave. He designed JBehave as a replacement for [http://junit.org/ JUnit], removing all references to testing and replacing them with a vocabulary built around verifying behavior.<ref>http://dannorth.net/introducing-bdd/</ref> Since then, the framework has undergone several updates and revisions, with the current stable release at version 3.9.4. Tools such as [https://github.com/arnaudbrejeon/cspec/wiki Cspec], [https://github.com/tpuronen/cppspec CppSpec], [http://nbehave.org/ NBehave], [http://phpspec.net/ PHPSpec], [http://pythonhosted.org/behave/ behave] and [http://rspec.info/ RSpec] now exist to support behavior-driven development in several popular languages.  
Towards the end of 2003, North, who had begun promoting BDD as a software development methodology, starting working on a Java framework called <b>JBehave</b>. He designed JBehave as a replacement for [http://junit.org/ JUnit], removing all references to testing and replacing them with a vocabulary built around verifying behavior.<ref name="dan" /> Since then, the framework has undergone several updates and revisions, with the current stable release at version 3.9.4. Tools such as [https://github.com/arnaudbrejeon/cspec/wiki Cspec], [https://github.com/tpuronen/cppspec CppSpec], [http://nbehave.org/ NBehave], [http://phpspec.net/ PHPSpec], [http://pythonhosted.org/behave/ behave] and [[CSC/ECE_517_Fall_2012/ch2a_2w30_an#RSpec|RSpec]] now exist to support behavior-driven development in several popular languages.  




====Stories and Scenarios====
====Stories and Scenarios====
BDD (and JBehave) revolves around the concept of a <b>Story</b>, which represents an automatically executable description of a requirement and its business benefit.<ref>http://jbehave.org/reference/stable/concepts.html</ref><ref>http://dannorth.net/whats-in-a-story/</ref> At its core a Story comprises of one or more <b>Scenarios</b>, each of which represents a concrete example of the behavior of the system. Each Scenario comprises of a number of executable steps. These Steps can be of three types:
BDD (and JBehave) revolves around the concept of a <b>Story</b>, which represents an automatically executable description of a requirement and its business benefit.<ref>[http://jbehave.org/reference/stable/concepts.html Stories, Scenarios and Steps]. Retrieved on 13 October 2014.</ref><ref>North, Dan. [http://dannorth.net/whats-in-a-story/ "What's in a Story?"]. Retrieved on 13 October 2014.</ref> At its core a Story comprises of one or more <b>Scenarios</b>, each of which represents a concrete example of the behavior of the system. Each Scenario comprises of a number of executable Steps. These Steps can be of three types:


*'''Given''' - Provides the context (precondition) to an event
*'''Given''' - Provides the context (precondition) to an event
Line 78: Line 95:
     '''Then''' the home page should be displayed
     '''Then''' the home page should be displayed


As shown in the example, BDD tests use a verbose style so that they can almost be read as sentences. The ability to read a test like a sentence represents a cognitive shift in how developers can think about their tests. Reading their tests fluidly can enable them to naturally write better and more comprehensive tests that actually model and help shape the behavior of a system.<ref>https://joshldavis.com/2013/05/27/difference-between-tdd-and-bdd/</ref>
The first part of the Story (As ... I want ... So ...) is the <b>Narrative</b>, which describes the roles, goals and the objective of the story.
 
As shown in the example, BDD tests use a verbose style so that they can almost be read as sentences. The ability to read a test like a sentence represents a cognitive shift in how developers can think about their tests. Reading their tests fluidly can enable them to naturally write better and more comprehensive tests that actually model and help shape the behavior of a system.<ref name="diff" />




Line 86: Line 105:


*JBehave Core - The main Java framework
*JBehave Core - The main Java framework
*JBehave Web - An extension of JBehave Core providing web-related functionalities
*JBehave Web - An extension of JBehave Core providing web-related functionality


JBehave takes full advantage of all the Java Virtual Machine and the numerous libraries available for Java.<ref>https://blog.codecentric.de/en/2012/06/jbehave-configuration-tutorial/</ref> It uses [http://jbehave.org/reference/stable/annotations.html annotations], which use [http://en.wikipedia.org/wiki/Regular_expression Regex] patterns as values, to map user stories to Java methods. It also uses a piece of code called the [http://jbehave.org/reference/stable/javadoc/core/org/jbehave/core/embedder/Embedder.html Embedder] which provides an entry point into all of JBehave's functionality such as - where to look for the story files, how to handle failures, which reports to output and so on.<ref>http://edgblog.wordpress.com/2013/07/08/an-introduction-to-jbehave/</ref>
JBehave takes full advantage of all the Java Virtual Machine and the numerous libraries available for Java.<ref>Ebbert-Karoum, Andreas. [https://blog.codecentric.de/en/2012/06/jbehave-configuration-tutorial/ "JBehave Configuration Tutorial"], 16 June 2012. Retrieved on 13 October 2014.</ref> It works by using [http://jbehave.org/reference/stable/annotations.html annotations], which use [http://en.wikipedia.org/wiki/Regular_expression Regex] patterns as values, to map user stories to Java methods. It also uses a piece of code called the [http://jbehave.org/reference/stable/javadoc/core/org/jbehave/core/embedder/Embedder.html Embedder] which provides an entry point into all of JBehave's functionality, such as - where to look for story files, how to handle failures, which reports to output, and so on.<ref>Edgeblog. [http://edgblog.wordpress.com/2013/07/08/an-introduction-to-jbehave/ "An introduction to JBehave"], 8 July 2013. Retrieved on 13 October 2014.</ref>


JBehave is primarily a Java API but it also has been expanded to include an [http://en.wikipedia.org/wiki/Eclipse_%28software%29 Eclipse] plugin as well as a [http://maven.apache.org/ Maven] plugin. Which in the background uses [http://www.seleniumhq.org/ Selenium] to do behavioral test cases against a web site.
JBehave is primarily a Java API but it also has been expanded to include an [http://en.wikipedia.org/wiki/Eclipse_%28software%29 Eclipse] plugin as well as a [http://maven.apache.org/ Maven] plugin, which in the background uses [http://www.seleniumhq.org/ Selenium] to do behavioral test cases against a web site.




===Features===
===Features===
<div style="padding-left:2em;">
<div style="padding-left:1em;">
*Pure java implementation
*Pure java implementation - allows for a clean API that can be easily extended.
*JUnit integration
*Text based user stories can be written in: JBehave syntax, [http://cukes.info/gherkin.html Gherkin] syntax, or [http://groovy.codehaus.org/ Groovy].
*Maven integration - allows automation of JBehave tasks at build time
</div>
*Ant integration
[[File:Jbehave-Eclipse1.png|frame|300px|A screenshot of the jBehave Eclipse Plugin|right]]
*Text based user stories can be written in: JBehave syntax, Gherkin syntax, or Groovy (Rob/Yogesh: Can we find examples of these?)
<div style="padding-left:1em;">
*Selenium Integration - allows automation of web based UI test cases
*Dependency Injection support allowing both configuration and Steps instances composed via your favorite container ([http://en.wikipedia.org/wiki/Google_Guice Guice], [http://needle.spree.de/overview Needle], [http://picocontainer.codehaus.org/ PicoContainer], [http://platform.spring.io/platform/ Spring], [http://weld.cdi-spec.org/ Weld]).<ref>[http://jbehave.org/reference/stable/features.html Features of JBehave]. Retrieved on 13 October 2014.</ref>
*Dependency Injection support allowing both configuration and Steps instances composed via your favorite container (Guice, Needle, PicoContainer, Spring, Weld)<ref>http://jbehave.org/reference/stable/features.html</ref>
*[[CSC/ECE_517_Fall_2013/ch1_1w32_av#Selenium|Selenium]] Integration - allows automation of web based UI test cases.
*Web Runner - a simple web-based non-technical interface that allows non-technical team members (Execs, BAs, QAs etc... ) to make contributions by generating stories. Run as a simple Jetty Web Service application from maven.  
*Web Runner - a simple web-based non-technical interface that allows non-technical team members (upper level management, [http://en.wikipedia.org/wiki/Business_analyst Business Analysts]s, etc.) to make contributions by generating stories. It is run as a simple Jetty Web Service application from Maven.
*Eclipse IDE Integration<ref>http://jbehave.org/eclipse-integration.html</ref>
*JUnit integration - allows the developer to see reports of tests plan runs.
*Syntax highlighting
*Maven integration - allows automation of JBehave tasks at build time .
*Step hyperlink detection and link to corresponding Java method
*[http://ant.apache.org/ Ant] integration - allows automation of JBehave tasks at build time.
*Step auto-completion
*Eclipse IDE Integration<ref>[http://jbehave.org/eclipse-integration.html Eclipse Integration]. Retrieved on 13 October 2014.</ref>
*Step validation, detecting both unimplemented steps and ambiguous steps, i.e. matching multiple methods
:*Syntax highlighting.
:*Step hyperlink detection and link to corresponding Java method.
:*Step auto-completion.
:*Step validation, detecting both unimplemented steps and ambiguous steps, i.e. matching multiple methods.
</div>
</div>
Figure 1. JBehave Plugin for Eclipse IDE




Line 116: Line 136:
   
   
There are five basic steps to using JBehave:  
There are five basic steps to using JBehave:  
#Setup a configuration file, called a “textual story” with all of your english verbiage in it. This textual story is very similar to [http://cukes.info/ Cucumber] test cases.
#Set up a configuration file, called a “textual story” with all of your English verbiage in it. This textual story is very similar to [http://cukes.info/ Cucumber] test cases.
#Next, write a [http://en.wikipedia.org/wiki/Plain_Old_Java_Object plain old java object] (POJO) and add annotations to it that match the actions in your “textual story”.
#Next, write a [http://en.wikipedia.org/wiki/Plain_Old_Java_Object plain old java object] (POJO) and add annotations to it that match the actions in your “textual story”.
#(only once) Write a simple configuration file that defines the relationship between your textual story file and your POJO, for instance, one-to-one.
#(Only once) Write a simple configuration file that defines the relationship between your textual story file and your POJO, for instance, one-to-one.
#Run your test case.
#Run your test case.
#Go over the outputted review files.
#Go over the outputted review files.


Begin by writing a “textual story” that tells a narrative:
 
*Begin by writing a “textual story” that tells a narrative:


  '''Given''' a cholesterol calculator
  '''Given''' a cholesterol calculator
Line 128: Line 149:
  '''Then''' the patient has LDL of 118.2.  
  '''Then''' the patient has LDL of 118.2.  


[''Note: for reference the calculation in use: LDL = total cholesterol – HDL – (triglycerides/5)'']
''Note: for reference the calculation in use is:'' [[file:LDLformula.png]]  


Next compose a POJO class that has annotations that match the first (bolded above) words from the textual story. These bolded terms will actually become the annotations in the POJO and will become the action steps taken by JBehave to run the test case. JBehave will actually use these key-words in the annotation and the story to look up the next action from the POJO to run.  
*Next, compose a POJO class that has annotations that match the first (bolded above) words from the textual story. These bolded terms will actually become the annotations in the POJO and will become the action steps taken by JBehave to run the test case. JBehave will actually use these key-words in the annotation and the story to look up the next action from the POJO to run.  
<pre>
<pre>
public class CalculateLDLTest {
public class CalculateLDLTest {
Line 152: Line 173:
}
}
</pre>
</pre>
Additionally, the story and pojo need to be wired together. This is done with a simple configuration POJO, that tells JBehave about the nature of the relationship between the story and the annotated POJO.
*Additionally, the story and POJO need to be wired together. This is done with a simple configuration POJO, that tells JBehave about the nature of the relationship between the story and the annotated POJO.
// Specify the mapping between the story and the pojo
<pre>
<pre>
// Specify the mapping between the story and the POJO
public class RunCholesterol extends JUnitStory {
public class RunCholesterol extends JUnitStory {


Line 172: Line 193:
</pre>
</pre>


Run the tests using the Eclipse JUnit plugin or Maven  
*Run the tests using the Eclipse JUnit plugin or Maven.
> mvn clean install
> mvn clean install
[ Rob: put output here ]
Review the output for the results
*You can then review the output for the results.


==JBehave Web==
==JBehave Web==
Line 182: Line 203:
===Web Runner===
===Web Runner===


Web Runner is an application developed using [http://www.oracle.com/technetwork/java/javase/overview/index.html Java Standard Edition (SE)] that allows non-technical business resources to contribute user stories concurrently. The system is run from a web application server such as [http://www.eclipse.org/jetty/ Jetty] or [http://tomcat.apache.org/ Tomcat]. It can be easily started via running the Maven target, “mvn jetty:run-war -Djbehave.webrunner.version=4.6” from inside the jbehave-web/web-runner folder inside the git repository. See Figure 2: Web Runner application to see a running example of Web Runner, where users can submit, run, or view stories from the simple web interface.
Web Runner is an application developed using [http://www.oracle.com/technetwork/java/javase/overview/index.html Java Standard Edition (SE)] that allows non-technical business resources to contribute user stories concurrently. The system is run from a web application server such as [http://www.eclipse.org/jetty/ Jetty] or [http://tomcat.apache.org/ Tomcat]. It can be easily started via running the Maven target:
mvn jetty:run-war -Djbehave.webrunner.version=4.6
from inside the jbehave-web/web-runner folder inside the git repository. View the image below to see a running example of Web Runner, where users can submit, run, or view stories from the simple web interface.


See figure: [http://www4.ncsu.edu/~rrmercer/runnerexample1.png "An example of the Web Runner interface"]


===Selenium Integration module===
===Selenium Integration module===


This module provides integration of JBehave's BDD with Selenium, an open-source suite of tools for automated web testing across various platforms. The module supports implementations in both the APIs provided by Selenium - the [http://docs.seleniumhq.org/docs/02_selenium_ide.jsp Selenium IDE] and the [http://docs.seleniumhq.org/docs/03_webdriver.jsp Selenium Webdriver].<ref>http://jbehave.org/reference/web/stable/using-selenium.html</ref> One would expect the step classes (which implement user story steps) to get cluttered with Selenium calls, as each step would typically require interactions with multiple web pages. However, JBehave uses elements called [http://jbehave.org/reference/web/stable/page-objects.html Page Objects] that allow users to easily access the objects for each page by abstracting Selenium's behavior behind pages. These page objects can then be injected into JBehave Step classes, as shown in the following example:
This module provides integration of JBehave's BDD with Selenium, an open-source suite of tools for automated web testing across various platforms. The module supports implementations in both the APIs provided by Selenium - the [http://docs.seleniumhq.org/docs/02_selenium_ide.jsp Selenium IDE] and the [http://docs.seleniumhq.org/docs/03_webdriver.jsp Selenium Webdriver].<ref name = "Selenium">[http://jbehave.org/reference/web/stable/using-selenium.html "Driving Web behavior with Selenium"]. Retrieved on 13 October 2014.</ref> When using JBehave's user stories with Selenium, one would expect the step classes (which implement user story steps) to get cluttered with Selenium calls, as each step would typically require interactions with multiple web pages. However, JBehave uses elements called [http://jbehave.org/reference/web/stable/page-objects.html Page Objects] that allow users to easily access the objects for each page by abstracting Selenium's behavior behind pages. These page objects can then be injected into JBehave Step classes, as shown in the following example:


  '''Given''' user is on Home page
  '''Given''' user is on Home page
Line 219: Line 243:
</pre>
</pre>


Once the step classes are defined, the integration of JBehave with Selenium can be done in one of several ways (such as having an [http://jbehave.org/reference/stable/javadoc/core/org/jbehave/core/class-use/Embeddable.html embeddable runnable class]). To automate Selenium tests, a [http://en.wikipedia.org/wiki/Application_server web application server] is required along with the Selenium server.
Once the step classes are defined, the integration of JBehave with Selenium can be done in one of several ways (such as having an [http://jbehave.org/reference/stable/javadoc/core/org/jbehave/core/class-use/Embeddable.html embeddable runnable class]). To automate Selenium tests, a [http://en.wikipedia.org/wiki/Application_server web application server] is required along with the Selenium server.<ref name="Selenium" />


==Criticism of JBehave==
Criticism of JBehave and BDD exist in the literature available. Most of criticism within the literature relating to JBehave relates to the rather difficult process of configuring the relationship between the story and the POJO. <ref name="jimmy">Cuadra, Jimmy. [http://www.jimmycuadra.com/posts/please-don-t-use-cucumber "Please don't use Cucumber"], 31 May 2012. Retrieved on 13 October 2014.</ref><ref>Harris, Martin. [http://martinaharris.com/2010/05/bad-or-good-bdd-within-scrum/ "Bad or good? BDD within Scrum"], 17 May 2010. Retrieved on 13 October 2014.</ref> Additional criticism of JBehave and BDD relates to the inability of some test cases to be tested automatically. <ref name="jimmy" />


==Further Reading==
==Further Reading==
#[http://www.ryangreenhall.com/articles/bdd-by-example.html BDD by example ]
#[[CSC/ECE_517_Fall_2014/ch1b_28_cg|TDD versus BDD]]
#[http://en.wikipedia.org/wiki/Behavior-driven_development BDD on Wikipedia]
#[http://www.ryangreenhall.com/articles/bdd-by-example.html BDD by example]
#[https://github.com/jbehave The consolidated JBehave repository on GitHub]
#[https://blog.codecentric.de/en/2012/06/jbehave-configuration-tutorial/ JBehave configuration tutorial]
#[https://blog.codecentric.de/en/2012/06/jbehave-configuration-tutorial/ JBehave configuration tutorial]
 
#[http://css.dzone.com/news/continuous-testing-selenium A simple Selenium implementation example using the Maven plugin]
#[http://java.dzone.com/articles/brief-comparison-bdd A brief comparison of BDD frameworks]
#[http://deepintojee.wordpress.com/2011/09/30/my-bad-i-would-rather-go-for-jbehave/ A user's perspective on JBehave's useful features]


==References==
==References==
<references/>
<references/>

Latest revision as of 05:02, 14 October 2014

Behavior-Driven Development using JBehave

JBehave is an open-source, Java-based Behavior-driven development (BDD) framework. It was originally developed by Dan North in 2003 to improve upon the underlying principles of Test-driven development.<ref>Vasilev, Nikolay. "BDD with JBehave and Selenium", 16 June 2011. Retrieved on 13 October 2014.</ref>

JBehave
Developer Dan North
Initial release 2003
Stable Release 3.9.4 - Aug. 24, 2014
Written in Java
Type BDD Framework
License BSD-style license<ref>"JBehave License". Retrieved on 13 October 2014.</ref>
jbehave.org


[Write-up 1b topics]


Background: Behavior-Driven Development as an evolution of Test-Driven Development

Behavior-Driven Development was conceived as an improvement to the thought processes behind Test-Driven Development (TDD) and Acceptance Test-Driven Planning.<ref>"The BDD Wiki". Retrieved on 13 October 2014.</ref>

The Test-driven development software development cycle<ref>Wikipedia. "A quick overview of the Test-driven development lifecycle", 12 July 2009. Retrieved on 13 October 2014.</ref>

Test-Driven Development

Test-driven development, which is often associated with Extreme Programming, is a software development technique which combines test-first development and Refactoring. TDD can be described at a high level as a process that iteratively follows the steps below:

  1. Add a test that tests for a required functionality.
  2. Get the test to fail.
  3. Write just enough code for the test to pass.
  4. Refactor the code to acceptable standards.


At each step along the process for TDD, the developer has to ensure that the new code which has been added does not affect previously written functionality, i.e. all tests written up to that point have to be re-run to ensure that everything is working as expected. TDD offers benefits such as: <ref>Base 36. "Benefits of test-driven development", 13 July 2012. Retrieved on 13 October 2014.</ref>

  • Maintainable, flexible and easily extensible code.
  • Unparalleled test coverage and a streamlined code-base.
  • A cleaner interface, since the APIs produced are written from an API-User perspective.
  • Better code quality through the emphasis on Refactoring.
  • Executable documentation in the form of tests.


Behavior-Driven Development and JBehave

Behavior-Driven Development is a development paradigm first proposed by Dan North, which aims to make development practices more accessible and intuitive to newcomers and experts alike by shifting the vocabulary from being test-based to behavior-based. It emphasizes communication and automation as equal goals.<ref>Introduction to BDD and JBehave. Retrieved on 13 October 2014.</ref> In essence, BDD tests focus more on the features, as opposed to the actual results of the tests. Consequently, BDD helps to design the software, not just test it.<ref name="diff">Davis, Josh L. "Difference between TDD and BDD", 27 May 2013. Retrieved on 13 October 2014.</ref>

BDD aims to bridge the gap between the differing views of computer systems held by business users and technologists by using terminology focused on the behavioral aspects of the system rather than testing. Its focus is on minimizing the hurdles between specification, design, implementation and confirmation of the behavior 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 extremely productive techniques.<ref>"BDD - Introduction (The BDD Wiki)". Retrieved on 13 October 2014.</ref>

In the words of Dan North, the creator of BDD and JBehave:<ref name = "dan">North, Dan. "Introducing BDD", March 2006. Retrieved on 13 October 2014.</ref>

I had a problem. While using and teaching agile practices like test-driven development (TDD) on projects in different environments, I kept coming across the same confusion and misunderstandings. Programmers wanted to know where to start, what to test and what not to test, how much to test in one go, what to call their tests, and how to understand why a test fails.

The deeper I got into TDD, the more I felt that my own journey had been less of a wax-on, wax-off process of gradual mastery than a series of blind alleys. I remember thinking “If only someone had told me that!” far more often than I thought “Wow, a door has opened.” I decided it must be possible to present TDD in a way that gets straight to the good stuff and avoids all the pitfalls.

My response is behavior-driven development (BDD). It has evolved out of established agile practices and is designed to make them more accessible and effective for teams new to agile software delivery. Over time, BDD has grown to encompass the wider picture of agile analysis and automated acceptance testing.


Towards the end of 2003, North, who had begun promoting BDD as a software development methodology, starting working on a Java framework called JBehave. He designed JBehave as a replacement for JUnit, removing all references to testing and replacing them with a vocabulary built around verifying behavior.<ref name="dan" /> Since then, the framework has undergone several updates and revisions, with the current stable release at version 3.9.4. Tools such as Cspec, CppSpec, NBehave, PHPSpec, behave and RSpec now exist to support behavior-driven development in several popular languages.


Stories and Scenarios

BDD (and JBehave) revolves around the concept of a Story, which represents an automatically executable description of a requirement and its business benefit.<ref>Stories, Scenarios and Steps. Retrieved on 13 October 2014.</ref><ref>North, Dan. "What's in a Story?". Retrieved on 13 October 2014.</ref> At its core a Story comprises of one or more Scenarios, each of which represents a concrete example of the behavior of the system. Each Scenario comprises of a number of executable Steps. These Steps can be of three types:

  • Given - Provides the context (precondition) to an event
  • When - Represents the occurrence of the event
  • Then - Occurrence of the event

These are known as BDD Keywords. Another keyword 'And' can also be used; it can be thought of as merely a substitution for the previously used keyword. A scenario can contain any number of steps, and steps of the same type can follow each other. The following example demonstrates the concept of a story:

Story: User login
  As a user
  I want to use my username and password to login
  So that I can view my home page
Scenario: User uses an incorrect password Given a username 'direwolf' And a password 'lannister' When the user logs in with username and password Then the login page should be displayed
Scenario: User uses a correct password Given a username 'direwolf' And a password 'stark' When the user logs in with username and password Then the home page should be displayed

The first part of the Story (As ... I want ... So ...) is the Narrative, which describes the roles, goals and the objective of the story.

As shown in the example, BDD tests use a verbose style so that they can almost be read as sentences. The ability to read a test like a sentence represents a cognitive shift in how developers can think about their tests. Reading their tests fluidly can enable them to naturally write better and more comprehensive tests that actually model and help shape the behavior of a system.<ref name="diff" />


JBehave

JBehave comprises of two components:

  • JBehave Core - The main Java framework
  • JBehave Web - An extension of JBehave Core providing web-related functionality

JBehave takes full advantage of all the Java Virtual Machine and the numerous libraries available for Java.<ref>Ebbert-Karoum, Andreas. "JBehave Configuration Tutorial", 16 June 2012. Retrieved on 13 October 2014.</ref> It works by using annotations, which use Regex patterns as values, to map user stories to Java methods. It also uses a piece of code called the Embedder which provides an entry point into all of JBehave's functionality, such as - where to look for story files, how to handle failures, which reports to output, and so on.<ref>Edgeblog. "An introduction to JBehave", 8 July 2013. Retrieved on 13 October 2014.</ref>

JBehave is primarily a Java API but it also has been expanded to include an Eclipse plugin as well as a Maven plugin, which in the background uses Selenium to do behavioral test cases against a web site.


Features

  • Pure java implementation - allows for a clean API that can be easily extended.
  • Text based user stories can be written in: JBehave syntax, Gherkin syntax, or Groovy.
A screenshot of the jBehave Eclipse Plugin
  • Dependency Injection support allowing both configuration and Steps instances composed via your favorite container (Guice, Needle, PicoContainer, Spring, Weld).<ref>Features of JBehave. Retrieved on 13 October 2014.</ref>
  • Selenium Integration - allows automation of web based UI test cases.
  • Web Runner - a simple web-based non-technical interface that allows non-technical team members (upper level management, Business Analystss, etc.) to make contributions by generating stories. It is run as a simple Jetty Web Service application from Maven.
  • JUnit integration - allows the developer to see reports of tests plan runs.
  • Maven integration - allows automation of JBehave tasks at build time .
  • Ant integration - allows automation of JBehave tasks at build time.
  • Eclipse IDE Integration<ref>Eclipse Integration. Retrieved on 13 October 2014.</ref>
  • Syntax highlighting.
  • Step hyperlink detection and link to corresponding Java method.
  • Step auto-completion.
  • Step validation, detecting both unimplemented steps and ambiguous steps, i.e. matching multiple methods.


Usage Details

There are five basic steps to using JBehave:

  1. Set up a configuration file, called a “textual story” with all of your English verbiage in it. This textual story is very similar to Cucumber test cases.
  2. Next, write a plain old java object (POJO) and add annotations to it that match the actions in your “textual story”.
  3. (Only once) Write a simple configuration file that defines the relationship between your textual story file and your POJO, for instance, one-to-one.
  4. Run your test case.
  5. Go over the outputted review files.


  • Begin by writing a “textual story” that tells a narrative:
Given a cholesterol calculator
When a patient has a total cholesterol of 201 (mg/dL) and a HDL of 74 and triglycerides of 44 
Then the patient has LDL of 118.2. 

Note: for reference the calculation in use is:

  • Next, compose a POJO class that has annotations that match the first (bolded above) words from the textual story. These bolded terms will actually become the annotations in the POJO and will become the action steps taken by JBehave to run the test case. JBehave will actually use these key-words in the annotation and the story to look up the next action from the POJO to run.
public class CalculateLDLTest {
	private LDLCalculator ldlCalculator;
	private float result;
	
	@Given (“a cholesterol calculator”)
	public void init(){
		ldlCalculator = new LDLCalculator();
        }

        @When (“a patient has a total cholesterol of $total and a HDL of $hdl and triglycerides of $tri”)
        public void populateValues(float total, float hdl, float tri){
	        result = ldlCalculator.calculate(total, hdl, tri);
        }

        @Then (“the patient has LDL of $ldl”)
        public void checkResult(float ldl){
	        assert.assertEquals(ldl, result, “Did not get the expected BMI”);
        }
}
  • Additionally, the story and POJO need to be wired together. This is done with a simple configuration POJO, that tells JBehave about the nature of the relationship between the story and the annotated POJO.
// Specify the mapping between the story and the POJO
public class RunCholesterol extends JUnitStory {

    @Override
    public Configuration configuration() {
        return new MostUsefulConfiguration()
            .useStoryLoader(new LoadFromClasspath(this.getClass()))  
            .useStoryReporterBuilder(new StoryReporterBuilder().withDefaultFormats().withFormats(Format.CONSOLE, Format.TXT)); 
    }
 
    // Here we specify the CalculateLDLTest classes
    @Override
    public InjectableStepsFactory stepsFactory() {        
        return new InstanceStepsFactory(configuration(), new CalculateLDLTest());
    }
}
  • Run the tests using the Eclipse JUnit plugin or Maven.
> mvn clean install
  • You can then review the output for the results.

JBehave Web

JBehave Web is an extension of JBehave Core, providing support for web-related access and functionality. The two main components of JBehave are:

Web Runner

Web Runner is an application developed using Java Standard Edition (SE) that allows non-technical business resources to contribute user stories concurrently. The system is run from a web application server such as Jetty or Tomcat. It can be easily started via running the Maven target:

mvn jetty:run-war -Djbehave.webrunner.version=4.6

from inside the jbehave-web/web-runner folder inside the git repository. View the image below to see a running example of Web Runner, where users can submit, run, or view stories from the simple web interface.

See figure: "An example of the Web Runner interface"

Selenium Integration module

This module provides integration of JBehave's BDD with Selenium, an open-source suite of tools for automated web testing across various platforms. The module supports implementations in both the APIs provided by Selenium - the Selenium IDE and the Selenium Webdriver.<ref name = "Selenium">"Driving Web behavior with Selenium". Retrieved on 13 October 2014.</ref> When using JBehave's user stories with Selenium, one would expect the step classes (which implement user story steps) to get cluttered with Selenium calls, as each step would typically require interactions with multiple web pages. However, JBehave uses elements called Page Objects that allow users to easily access the objects for each page by abstracting Selenium's behavior behind pages. These page objects can then be injected into JBehave Step classes, as shown in the following example:

Given user is on Home page
When user clicks on Logout
Then Login page is shown
public class LogoutSteps {
 
    private final Pages pages;
 
    public LogoutSteps(Pages pages) {
        this.pages = pages;
    }
 
    @Given("user is on Home page")
    public void userIsOnHomePage(){       
        pages.home().open();       
    }
 
    @When("user clicks on Logout")
    public void userClicksOnLogout(){       
        pages.home().click(logout);
    }
 
    @Then("Login page is shown")
    public void loginPageIsShown(){
        pages.login().pageIsShown();
    }
}

Once the step classes are defined, the integration of JBehave with Selenium can be done in one of several ways (such as having an embeddable runnable class). To automate Selenium tests, a web application server is required along with the Selenium server.<ref name="Selenium" />

Criticism of JBehave

Criticism of JBehave and BDD exist in the literature available. Most of criticism within the literature relating to JBehave relates to the rather difficult process of configuring the relationship between the story and the POJO. <ref name="jimmy">Cuadra, Jimmy. "Please don't use Cucumber", 31 May 2012. Retrieved on 13 October 2014.</ref><ref>Harris, Martin. "Bad or good? BDD within Scrum", 17 May 2010. Retrieved on 13 October 2014.</ref> Additional criticism of JBehave and BDD relates to the inability of some test cases to be tested automatically. <ref name="jimmy" />

Further Reading

  1. TDD versus BDD
  2. BDD on Wikipedia
  3. BDD by example
  4. The consolidated JBehave repository on GitHub
  5. JBehave configuration tutorial
  6. A simple Selenium implementation example using the Maven plugin
  7. A brief comparison of BDD frameworks
  8. A user's perspective on JBehave's useful features

References

<references/>