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

From Expertiza_Wiki
Jump to navigation Jump to search
No edit summary
(Formatted, with basic article structure)
Line 1: Line 1:
JBehave is an open source BDD Testing framework written in Java. (JBehave is an open-source, Java-based [Behaviour-driven development] BDD) framework) It was originally developed by Dan North in 2003 to compare TDD to BDD [1].  
==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] [1].  
 
 
__TOC__
 


==Background: BDD as an evolution of TDD==
==Background: BDD as an evolution of TDD==


Behaviour-Driven Development was conceived as an improvement to the thought processes behind [Test-Driven Development] (TDD) and [Acceptance Test-Driven Planning [1]].[2].
Behavior-Driven Development was conceived as an improvement to the thought processes behind [Test-Driven Development] (TDD) and [Acceptance Test-Driven Planning [1]].[2].


==={{Anchor|TDD|Test-Driven Development}}TDD===
===TDD===
[[File:Test-driven development.png|thumb|500px|The Test-driven development software development cycle]]
[[File:TestDrivenDevelopment.png|frame|300px|The Test-driven development software development cycle]]
Test-driven development, which is often associated with [ExtremeProgramming], 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:
Test-driven development, which is often associated with [ExtremeProgramming], 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:


#Add a test that tests for a required functionality.
#Add a test that tests for a required functionality.
Line 14: Line 20:
#Refactor the code to acceptable standards.
#Refactor the code to acceptable standards.


Image - [http://en.wikipedia.org/wiki/Test-driven_development#mediaviewer/File:Test-driven_development.PNG]


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 upto that point have to be re-run to ensure that everything is working as expected. TDD offers benefits such as: [3]
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: [3]


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




===BDD and JBehave===
===BDD and JBehave===


Behaviour-Driven Development is a development paradigm which aims to make development practices more accessible and intuitive to newcomers and experts alike, but by shifting the vocabulary from being test-based to behaviour-based. It emphasizes communication and automation as equal goals[4]. 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.[5]
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[4]. 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.[5]


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 behavioural aspects of the system rather than testing. Its focus is on minimizing the hurdles between specification, design, implementation and confirmation of the behaviour 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.[6]
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.[6]


In the words of Dan North, the creator of BDD and JBehave:[7]


In the words of Dan North, the founder of BDD and JBehave:[7]


<blockquote>
<blockquote style="text-indent:2em;"><p>
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.
''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.<br></p>
 
<p>
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.
''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.<br>
 
</p>
My response is behaviour-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.
<p>
''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.
</p>
</blockquote>
</blockquote>




BDD revolves around the concept of a <b>Story</b>, which represents an automatically executable description of a requirement and its business benefit [8][9]. At its core a Story comprises of one or more <b>Scenarios</b>, each of which represents a concrete example of the behaviour of the system. Each Scenario comprises of a number of executable steps. These Steps can be of three types:
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[7]. Since then, the framework has undergone several updates and revision, with the current stable release at version 3.9.4. Tools such as [Cspec], [CppSpec], [NBehave], [Cuke4Duke], [PHPSpec], [behave] and [Cucumber] now exist to support behavior-driven development in several popular languages.  
*'''Given''' - Provides the context (precondition) to an event
*'''When''' - Represents the occurence of the event
*'''Then''' - Occurence of the event
These are known as BDD Keywords. Another keyword '''And''' can also be used; 'And' 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
;In order to access my home page
;As a user
;I want to use my username and password to login


'''Scenario:''' User uses an incorrect password
====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 [8][9]. 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''' a username 'direwolf'
*'''Given''' - Provides the context (precondition) to an event
;'''And''' a password 'lannister'
*'''When''' - Represents the occurrence of the event
'''When''' the user logs in with username and password
*'''Then''' - Occurrence of the event
'''Then''' the login page should be displayed


'''Scenario:''' User uses a correct password
These are known as BDD Keywords. Another keyword '<b>And</b>' 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:


  '''Given''' a username 'direwolf'
  '''Story:''' User login
'''And''' a password 'stark'
  As a user
'''When''' the user logs in with username and password
  I want to use my username and password to login
'''Then''' the home page should be displayed
  So that I can view my home page<br>
 
  '''Scenario:''' User uses an incorrect password
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 is a cognitive shift in how developers thinks about their tests. Reading their tests fluidly will enable them to naturally write better and more comprehensive tests that actual model and help shape the behaviour of a system.[5]
    '''Given''' a username 'direwolf'
    '''And''' a password 'lannister'
    '''When''' the user logs in with username and password
    '''Then''' the login page should be displayed<br>
  '''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


BDD tools such as [Cspec], [CppSpec], [NBehave], [Cuke4Duke], [PHPSpec], [behave] and [Cucumber] now exist to support behaviour-driven development in several popular languages. JBehave is one such framework for Java which was created by BDD founder Dan North as an implementation of his newly conceived development principles.
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 think about their tests. Reading their tests fluidly will enable them to naturally write better and more comprehensive tests that actual model and help shape the behavior of a system.[5]




Line 78: Line 86:




==Features==
===Features===
 
<div style="padding-left:2em;">
*Pure java implementation
*Pure java implementation
*Junit integration
*Junit integration
Line 86: Line 94:
*Text based user stories can be written in: JBehave syntax, Gherkin syntax, or Groovy (Rob/Yogesh: Can we find examples of these?)
*Text based user stories can be written in: JBehave syntax, Gherkin syntax, or Groovy (Rob/Yogesh: Can we find examples of these?)
*Selenium Integration - allows automation of web based UI test cases
*Selenium Integration - allows automation of web based UI test cases
*Dependency Injection support allowing both configuration and Steps instances composed via your favourite container (Guice, Needle, PicoContainer, Spring, Weld) [4]
*Dependency Injection support allowing both configuration and Steps instances composed via your favorite container (Guice, Needle, PicoContainer, Spring, Weld) [4]
*WebRunner - 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.  
*WebRunner - 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.  
*Eclipse IDE Integration [2]  
*Eclipse IDE Integration [2]  
*Syntax highlighting
*Syntax highlighting
*Step hyperlink detection and link to corresponding Java method
*Step hyperlink detection and link to corresponding Java method
*Step autocompletion
*Step auto-completion
*Step validation, detecting both unimplemented steps and ambiguous steps, i.e. matching multiple methods
*Step validation, detecting both unimplemented steps and ambiguous steps, i.e. matching multiple methods
</div>


Figure 1. jBehave Plugin for Eclipse IDE
Figure 1. JBehave Plugin for Eclipse IDE




== Usage Details ==
===Usage Details===
   
   
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 Cucumber test cases.
#Setup 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.
#Next, write a POJO and add annotations to it that match the actions in your “textual story”.
#Next, write a [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
 
When a patient has a total cholesterol of 201 (mg/dL) and a HDL of 74 and triglycerides of 44  
'''Given''' a cholesterol calculator
Then the patient has LDL of 118.2. [''Note: for reference the calculation in use: LDL = total cholesterol – HDL – (triglycerides/5)'']
'''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: LDL = total cholesterol – HDL – (triglycerides/5)'']


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.  
<source lang="java">
<pre>
public class CalculateLDLTest {
public class CalculateLDLTest {
private LDLCalculator ldlCalculator;
private LDLCalculator ldlCalculator;
Line 120: Line 132:
public void init(){
public void init(){
ldlCalculator = new LDLCalculator();
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){
        @When (“a patient has a total cholesterol of $total and a HDL of $hdl and triglycerides of $tri”)
result = ldlCalculator.calculate(total, hdl, tri);
        public void populateValues(float total, float hdl, float tri){
}
        result = ldlCalculator.calculate(total, hdl, tri);
        }


@Then (“the patient has LDL of $ldl”)
        @Then (“the patient has LDL of $ldl”)
public void checkResult(float ldl){
        public void checkResult(float ldl){
assert.assertEquals(ldl, result, “Did not get the expected BMI”);
        assert.assertEquals(ldl, result, “Did not get the expected BMI”);
        }
}
}
}
</pre>
</source>
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
// Specify the mapping between the story and the pojo
<source lang="java">
<pre>
public class RunCholesterol extends JUnitStory {
public class RunCholesterol extends JUnitStory {


Line 150: Line 163:
     }
     }
}
}
</source>
</pre>


Run the tests using the Eclipse Junit plugin or maven  
Run the tests using the Eclipse Junit plugin or maven  
Line 168: Line 181:
Example: Yogesh -- I’d like to see/do a selenium example. there are plenty of examples  
Example: Yogesh -- I’d like to see/do a selenium example. there are plenty of examples  
(http://jbehave.org/reference/web/stable/using-selenium.html)  
(http://jbehave.org/reference/web/stable/using-selenium.html)  
==Further Reading==
BDD by example [http://www.ryangreenhall.com/articles/bdd-by-example.html]





Revision as of 06:00, 5 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] [1].



Background: BDD as an evolution of TDD

Behavior-Driven Development was conceived as an improvement to the thought processes behind [Test-Driven Development] (TDD) and [Acceptance Test-Driven Planning [1]].[2].

TDD

The Test-driven development software development cycle

Test-driven development, which is often associated with [ExtremeProgramming], 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: [3]


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


BDD 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[4]. 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.[5]

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.[6]

In the words of Dan North, the creator of BDD and JBehave:[7]


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[7]. Since then, the framework has undergone several updates and revision, with the current stable release at version 3.9.4. Tools such as [Cspec], [CppSpec], [NBehave], [Cuke4Duke], [PHPSpec], [behave] and [Cucumber] 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 [8][9]. 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

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 think about their tests. Reading their tests fluidly will enable them to naturally write better and more comprehensive tests that actual model and help shape the behavior of a system.[5]


JBehave

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. [More here]


Features

  • Pure java implementation
  • Junit integration
  • Maven integration - allows automation of jBehave tasks at build time
  • Ant integration
  • Text based user stories can be written in: JBehave syntax, Gherkin syntax, or Groovy (Rob/Yogesh: Can we find examples of these?)
  • Selenium Integration - allows automation of web based UI test cases
  • Dependency Injection support allowing both configuration and Steps instances composed via your favorite container (Guice, Needle, PicoContainer, Spring, Weld) [4]
  • WebRunner - 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.
  • Eclipse IDE Integration [2]
  • 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

Figure 1. JBehave Plugin for Eclipse IDE


Usage Details

There are five basic steps to using JBehave:

  1. Setup 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: LDL = total cholesterol – HDL – (triglycerides/5)]

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 [ Rob: put output here ] Review the output for the results

JBehave Web

JBehave Web is an extension of JBehave Core, providing support for web-related access or functionality. It has the following two components:

WebRunner

WebRunner 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 repo. See Figure 2: WebRunner application to see a running example of WebRunner, where users can submit, run, or view stories from the simple web interface.


Selenium

Example: Yogesh -- I’d like to see/do a selenium example. there are plenty of examples (http://jbehave.org/reference/web/stable/using-selenium.html)


Further Reading

BDD by example [1]


References

[1]http://www.slideshare.net/shadrik/bdd-with-java-8323915 [2]http://jbehave.org/eclipse-integration.html [3]http://jbehave.org/reference/web/stable/using-web-runner.html [4]http://jbehave.org/reference/stable/features.html

[1]http://testdrivendeveloper.com/2008/04/02/AcceptanceTestDrivenDevelopmentExplained.aspx [2]http://behaviour-driven.org/ [3]http://www.base36.com/2012/07/benefits-of-test-driven-development/ [4]http://jbehave.org/introduction.html [5]https://joshldavis.com/2013/05/27/difference-between-tdd-and-bdd/ [6]http://behaviour-driven.org/Introduction [7]http://dannorth.net/introducing-bdd/ [8]http://jbehave.org/reference/stable/concepts.html [9]http://dannorth.net/whats-in-a-story/