Modified docs as per suggestions and cleared the mess

SUMMARY.md

@@ -10,7 +10,7 @@
 
 ### Behaviour-Driven Development
 
-* [Introduction to BDD](#)
+* [Introduction to BDD](docs/bdd-introduction)
 * [Roles](#)
   * [Domain Expert](#)
   * [Developer](#)
@@ -29,24 +29,25 @@
       * [Discovery Workshop](#)
       * [Deliberate Discovery](#)
     * [Event Storming](#)
-  * [Cucumber](#)
-    * [Living Documentation](#)
+  * [Cucumber](docs/cucumber.md)
+    * [Living Documentation](docs/living-documentation)
       * [Incidental Details](#)
       * [Example Mapping Output](#)
     * [Organising Gherkin](#)
     * [Organising Step Definitions](#)
   * [Programming](#)
     * [Modelling by Example](#)
-    * [Test-Driven Development](#)
+    * [Test-Driven Development](docs/tdd-introduction)
       * [Outer Cycle](#)
       * [Inner Cycle](#)
     * [Ports and Adapters](#)
   * [Testing](#)
     * [Test Pyramid](#)
     * [Shallow Tests](#)
     * [Narrow Tests](#)
-    * [UI Testing](#)
-      * [Selenium WebDriver](#)
+    * [UI Testing](docs/ui-testing)
+      * [Selenium WebDriver](docs/selenium-webdriver)
+	  * [Watir WebDriver](docs/watir-webdriver)
     * [Databases](#)
     * [Web Services](#)
     * [Domain Layer](#)

docs/bdd-introduction.md

@@ -0,0 +1,40 @@
+
+## Behavior Driven Development(BDD):
+
+   Behavior driven development (or BDD) is an software development technique that encourages collaboration between developers, QA and non-technical or business participants in a software project.
+
+   BDD focuses on obtaining a clear understanding of desired software behavior through discussion with stakeholders. It extends [TDD](docs/tdd-introduction) by writing test cases in a natural language that non-programmers can read. Behavior-driven developers use their native language in combination with the ubiquitous language of domain driven design to describe the purpose and benefit of their code. This allow the developers to focus on why the code should be created, rather than the technical details, and minimizes translation between the technical language in which the code is written and the domain language spoken by the business, users, stakeholders, project management, etc.
+
+   Coming to reality, Customer is a person who is an expert in dealing the things other than Technology. They need not to be aware of Edge case scenarios,beta testing and Alpha testing and so on. Even if he(customer) is familiar of the Technology stack,the only thing that is evolving in much faster pace is business, which change at constant pace.
+
+   In this modern Agile world, teams understand the business change and structure their approach according to the business needs.Rather than attempt to conceive, build, and deliver the perfect application in one fell swoop, they steadily deliver work in small and usable chunks for every week continously.  The customer is encouraged to think in terms of what functionality will be delivered at the maximum benefit to the business and prioritize the pipeline of work accordingly.
+
+  ![misconception between the team](images/problems.png)
+
+  A team using Behaviour Driven Development use conversations and collaboration around concrete examples to build up a shared understanding of the features they are supposed to build. Conversations about concrete examples, and counter-examples, are a great way to flush out any hidden assumptions or misunderstandings about what a feature needs to do.[1]
+
+  *This is expressed as a story using the following template:*
+
+|As a Role
+|-
+|I request a Feature
+|To gain a Benefit
+|The speaker, who holds the Role, is the person who will gain the Benefit from the requested Feature.
+
+This can also be paraphrased variously as ...
+
+I want to achieve a specific Goal, and as a Role I should be able to accomplish this by performing Functionality.A Role invokes Feature to cause a Benefit[2]
+
+Software teams work best when the developers and business stakeholders are communicating clearly with one another. A great way to do that is to ollaboratively specify the work that’s about to be done using automated acceptance tests.
+
+When the acceptance tests are written as examples, they stimulate people’s imaginations and help them see other scenarios they hadn’t previously considered.
+
+When the team write their acceptance tests collaboratively, they can develop their own ubiquitous language for talking about their problem domain.This helps them avoid misunderstandings.[3]
+
+
+   **"Behavior-driven development is about implementing an application by describing its behavior from the perspective of its stakeholders”** -- Dan North
+
+---
+[1] [*BDD FUNDAMENTAL*](http://thucydides.info/docs/articles/an-introduction-to-serenity-bdd-with-cucumber.html)
+[2] *BDD PROCESS*
+[3] *THE CUCUMBER BOOK*

docs/cucumber.md

@@ -0,0 +1,41 @@
+#Cucumber:
+
+   Cucumber is a [command-line tool](https://en.wikipedia.org/wiki/Command-line_interface). When you run it, it reads in your specifications from plain-language text files called features, examines them for scenarios to test, and runs the scenarios against your system. Each scenario is a list of steps for Cucumber to work through. So that Cucumber can understand these feature files, they must follow some basic syntax rules. The name for this set of rules is [Gherkin](docs/gherkin.md).
+
+ ![Cucumber_role](images/cucumber_core.png)
+
+Along with the features, you give Cucumber a set of step definitions, which map the business-readable language of each step into programming code to carry out
+whatever action is being described by the step. In a mature test suite, the step definition itself will probably just be one or two lines of code that delegate to a library of support code, specific to the domain of your application, that knows how to carry out common tasks on the system. Normally that will involve using an automation library, like the browser automation library Capybara, to interact with the system itself.[2]
+
+
+##BDD with Cucumber:
+   What makes Cucumber to stand out from the crowd of other communication and collaboration tools is that it has been designed specifically to ensure the acceptance tests can easily be read and written by anyone on the team. This reveals the true value of acceptance tests: as a communication and collaboration tool. The easy readability of Cucumber tests draws business stakeholders into the process, helping you really explore and understand their requirements.
+
+   Here is an example of a Cucumber acceptance test:
+
+ ```gherkin 
+Feature: Sign up Sign up should be quick and friendly**
+
+Scenario: Successful sign up.  New users should get a confirmation email and greeted personally by the site once signed in.
+
+Given I have chosen to sign up
+When I sign up with valid details
+Then I should receive a confirmation email
+And I should see a personalized greeting message
+```
+
+```gherkin
+Scenario: Duplicate email. Where someone tries to create an account for an email address that already exists.
+
+Given I have chosen to sign up
+But I specify an email address that has already registered
+Then I should be told that the email is already registered
+And I should be offered the option to recover my password
+
+ ```
+   Notice how these tests are specified as examples of the way we want the system to behave in particular scenarios. Using examples like this has an unexpectedly powerful effect in enabling people to visualize the system before it has been built. Anyone from the team can go through the Feature file an can understand what is the system for, And how it works(functionality).This helps in analyzing the functionality of the system and come up with more scenarios where the system/software can be tested thoroughly
+
+   In this way, we say that the story functions as a living document.  As the behavior of the system evolves over time, the team is forced to evolve the documentation in parallel.
+
+  Acceptance tests written in this style become more than just tests,they are executable specifications along with [living documentation](docs/living-documentation).
+

docs/living-documentation.md

@@ -0,0 +1,6 @@
+##Living Documnetation
+
+Cucumber tests share the benefit of traditional specification documents in that they can be written and read by business stakeholders, but they have a distinct advantage in that you can give them to a computer at any time to tell you how accurate they are. In practice, this means that your documentation, rather than being something that�s written once and then gradually goes out of date, becomes a [living document](https://en.wikipedia.org/wiki/Living_document) that reflects the true state of the project.
+
+###Source of Truth
+For many teams, they become the definitive source of truth as to what the system does. Having a single place to go for this information saves a lot of time that is often wasted trying to keep requirements documents, tests, and code all in sync. It also helps to build trust within the team, because different parts of the team no longer have their own personal versions of the truth.

docs/selenium-webdriver.md

@@ -0,0 +1,79 @@
+## Selenium WebDriver
+ WebDriver is designed to provide a simpler, more concise programming interface in addition to addressing some limitations in the Selenium-RC API. Selenium-WebDriver was developed to better support dynamic web pages where elements of a page may change without the page itself being reloaded. WebDriver�s goal is to supply a well-designed object-oriented API that provides improved support for modern advanced web-app testing problems.
+
+Let us see an example how cucumber can fit into selenium-webdriver in UI testinng, by converting [Selenium-Web driver by example     ](http://docs.seleniumhq.org/docs/03_webdriver.jsp#introducing-the-selenium-webdriver-api-by-example "Selenium-Webdriver by Example tutorial")
+
+ We can express the example as the following Scenario:
+
+ ```gherkin
+ Scenario: Finding some cheese
+   Given I am on the Google search page
+   When I search for "Cheese!"
+   Then the page title should start with "cheese"
+
+ ```java
+
+ USING JAVA
+ {% codetabs name="Java", type="java" -%}
+ package class.exmple;
+
+ public class ExampleSteps {
+
+      private final WebDriver driver = new FirefoxDriver();
+      @Given("^I am on the Google search page$"\)
+      public void I_visit_google() {
+      driver.get("https:\\www.google.com");
+     }
+
+     @When("^I search for \"(.*)\"$")
+       public void search_for(String query) {
+          WebElement element = browser.findElelment(By.name("q"));
+          \\Enter Something to search for
+          element.sendKeys(query);
+          \\Now submit the form. WebDriver will find the form for us from the element
+          element.submit();
+     }
+
+     @Then("^ the page title should start with \"(.*)\"$")
+     public void checkTitle() {
+        \\Google's search is rendered dynamically with JavaScript.
+        \\Wait for the page to load timeout after 10 second
+         (new WebDriverWait(driver, 10)).untill(new ExpectedCondition<Boolean> {
+         public Boolean apply(WebDriver d) {
+         return d.getTitle().toLowerCase.startsWith("cheese");
+         \\Should see: "cheese! -Google Search"
+      }
+
+ @After()
+   public void closeBrowser() {
+     driver.quit();
+   }
+ }
+{%- endcodetabs %}
+ ```
+
+```ruby
+ USING RUBY:
+ {% codetabs name="Ruby", type="rb" -%}
+ require 'rubygems'
+ require 'selenium-webdriver'
+
+ Given("^I am on the Google search page$") do
+  driver = Selenium::WebDriver.for :firefox
+  driver.get "http:\\google.com"
+ end
+
+ When("^I search for "([^"]*)"$") do
+  element = driver.find_element(:name => "q")
+  element.send_keys "Cheese!"
+  element.submit
+ end
+
+ Then("^the page title should start with "([^"]*)"$") do
+  wait = Selenium::WebDriver::Wait.new(:timeout => 10)
+  wait.until { driver.title.downcase.start_with? "cheese!" }
+  puts "Page title is #{driver.title}"
+   browser.close
+ end
+{%- endcodetabs %}
+```

docs/tdd-introduction.md

@@ -0,0 +1,43 @@
+
+
+## Test Driven Development
+
+Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: requirements are turned into very specific test cases, then the software is improved to pass the new tests. This is opposed to software development that allows software to be added that isn't proven to meet requirements.[1] Begin by writing a very small test for code that does not yet exist. Run the test and, naturally, it fails. Now write just enough code to make that test pass. Once the test passes, observe the resulting design and re-factor to remove any duplication you see. It is natural at this point to judge the design as too simple to handle all of the responsibilities this code will have.
+
+As the code base gradually increases in size, more and more attention is consumed by the re-factoring step. The design is constantly evolving and under constant review, though it is not predetermined. This process is known as emergent design, and is one of the most significant by products of Test Driven Development. 
+
+
+Clean code that works, in Ron Jeffries' pithy phrase, is the goal of Test-Driven Development
+(TDD). Clean code that works is a worthwhile goal for a whole bunch of reasons.
+* It is a predictable way to develop. You know when you are finished, without having to worry about a long bug trail.
+* It gives you a chance to learn all of the lessons that the code has to teach you. If you only slap together the first thing you think of, then you never have time to think of a second, better thing.
+* It improves the lives of the users of your software.
+* It lets your teammates count on you, and you on them.
+* It feels good to write it.
+
+But how do we get to clean code that works? Many forces drive us away from clean code,and even from code that works. Without taking too much counsel of our fears, here's what we do: we drive development with automated tests, a style of development called Test Driven Development (TDD). 
+
+In Test-Driven Development, we 
+* Write new code only, if an automated test has failed 
+* Eliminate duplication
+
+These are two simple rules, but they generate complex individual and group behavior with technical implications such as the following.
+* We must design organically, with running code providing feedback between decisions.
+* Programmers must write their own tests, because we can't wait 20 times per day for someone else to write a test.
+* Our development environment must provide rapid response to small changes.
+* Our designs must consist of many highly cohesive, loosely coupled components, just to make testing easy.
+
+The two rules imply an order to the tasks of programming.
+1. **Red**— Write a little test that doesn't work, and perhaps doesn't even compile at first.
+2. **Green**— Make the test work quickly, committing whatever sins necessary in the process.
+3. **Refactor**— Eliminate all of the duplication created in merely getting the test to work.
+**Red/green/refactor—the TDD mantra.**[2]
+
+![tdd_process](images/tdd2.png)
+
+
+---
+
+[1] [*TDD Wiki*](https://en.wikipedia.org/wiki/Test-driven_development)
+
+[2] *Test Driven Development by Kent Beck*

docs/ui-testing.md

@@ -0,0 +1,19 @@
+##UI-Testing
+
+ User interface testing, a testing technique used to identify the presence of defects is a product/software under test by using Graphical user interface [GUI].
+
+ ###GUI Testing - Characteristics:
+  *GUI is a hierarchical, graphical front end to the application, contains graphical objects with a set of properties.
+  *During execution, the values of the properties of each objects of a GUI define the GUI state.
+  *It has capabilities to exercise GUI events like key press/mouse click.
+  *Able to provide inputs to the GUI Objects.
+  *To check the GUI representations to see if they are consistent with the expected ones.
+  *It strongly depends on the used technology.
+
+ ###GUI Testing Checklist:
+  *Check Screen Validations
+  *Verify All Navigations
+  *Check usability Conditions
+  *Verify Data Integrity
+  *Verify the object states
+  *Verify the date Field and Numeric Field Formats

docs/watir-webdriver.md

@@ -0,0 +1,63 @@
+##Watir Webdriver
+
+Watir, pronounced water, is an open-source (BSD) family of Ruby libraries for automating web browsers. It allows you to write tests that are easy to read and maintain. It is simple and flexible.
+
+ Watir drives browsers the same way people do. It clicks links, fills in forms, presses buttons. Watir also checks results, such as whether expected text appears on the page.
+
+ Watir is a family of Ruby libraries but it supports your app no matter what technology it is developed in. While Watir supports only Internet Explorer on Windows, Here comes Watir-WebDriver to solve single browser testing and support Chrome, Firefox, Internet Explorer, Opera and also running in headless mode (HTMLUnit).
+
+ Now without wasting anytime quickly jump in to a sample UI testing program using Watir
+
+ ```ruby
+ {% codetabs name="Ruby", type="rb" -%}
+ require "rubygems"
+ require "rspec"
+ require "watir-webdriver"
+
+ describe "google.com" do
+   let(:browser) { @browser ||= Watir::Browser.new :firefox } 
+   before { browser.goto "http://google.com" } 
+   browser.text_field(:name => "q").set "watir"
+   browser.button.click 
+   browser.div(:id => "resultStats").wait_until_present
+   browser.title.should == "watir - Google Search"
+   after { browser.close }
+ end
+ {%- endcodetabs %}
+
+ ```
+
+ Now let us incorporate Cucumber to this simple test
+
+ ```gherkin
+ Feature: Search In order to use Google users must be able to search for content 
+   Scenario: Search for a term
+     Given I have entered "watir" into the query
+     When I click "search"
+     Then I should see some results
+
+
+  ```
+
+  ```ruby
+ {% codetabs name="Ruby", type="rb" -%}
+ require "watir-webdriver"
+ require "rspec/expectations"
+
+ Given /^I have entered "([^"]*)" into the query$/ do |term|
+   @browser ||= Watir::Browser.new :firefox
+   @browser.goto "google.com"
+   @browser.text_field(:name => "q").set term
+ end
+
+ When /^I click "([^"]*)"$/ do |button_name|
+   @browser.button.click
+ end
+
+ Then /^I should see some results$/ do
+   @browser.div(:id => "resultStats").wait_until_present
+   @browser.div(:id => "resultStats").should exist 
+   @browser.close
+ end
+
+ {%- endcodetabs %}