Cucumber presenation

Cucumber presenation

• 1.
  Presented by :Ben Wafi Oussama 1
• 2.
  PLAN • 1 Introduction • 2 Defintion • 3 Gherkin • 4 Gherkin Source File • 5 Cucumber & BDD • 6-Installation • 7-Running • 8-Demo • 9-Conclusion 2
• 3.
  Introduction(1/2) • Cucumber letssoftware development teams describe how software should behave in plain text. The text is written in a business readable domain specific-language and serves as documentation, automated tests and development-aid - all rolled into one format. • Cucumber works with Ruby, Java, .NET, Flex or web applications written in any language. It has been translated to over 40 spoken languages. 3
• 4.
  Introduction(2/2) 1: Describe behaviorin plain text 2: Write a step definition in Ruby 3: Run and watch it fail 4. Write code to make the step pass 5. Run again and see the step pass 6. Repeat 2-5 until green like a cuke 4
• 5.
  Definition • Cucumber isa tool that executes plain-text functional descriptions as automated tests. The language that Cucumber understands is called Gherkin It is a Business Readable, Domain Specific Language that lets you describe software’s behavior without detailing how that behavior is implemented. 5
• 6.
  Definition • Cucumber itselfis written in Ruby, but it can be used to “test” code written in Ruby or other languages including but not limited to Java, C# and Python. 6
• 7.
  Gherkin(1/3) • Gherkin servestwo purposes – documentation and automated tests • Gherkin’s grammar is defined in the Treetop grammar that is part of the Cucumber codebase. The grammar exists in different flavors for many spoken languages (37 at the time of writing), so that your team can use the keywords in your own language. • Source files have .feature extension. 7
• 8.
  Gherkin Syntax(2/3) • LikePython and YAML, Gherkin is a line- oriented language that uses indentation to define structure. Line endings terminate statements (eg, steps). • Parser divides the input into features, scenarios and steps. When you run the feature the trailing portion (after the keyword) of each step is matched to a Ruby code block called Step Definitions. 8
• 9.
  Gherkin Syntax(3/3) • "en": { • "ar": { • "name": "English", • "name": "Arabic", • "native": "English", • "native": " • "feature": "Feature|Busines Need|Ability", • feature": " • "background": "Background", • background": " • "scenario": "Scenario", • scenario": " • "scenariooutline":"ScenariOutline|Scenar • scenario_outline": " • "examples": "Examples|Scenarios", • examples": " • "given": "*|Given", • given": "*| • "when": "*|When", • when": "*| • "then": "*|Then", • then": "*| • "and": "*|And", • and": "*| • "but": "*|But" • but": "*| • }, • 9
• 10.
  A Gherkin sourcefile usually looks like this 1: Feature: Some terse yet descriptive text of what is desired 2: In order to realize a named business value 3: As an explicit system actor 4: I want to gain some beneficial outcome which furthers the goal 5: 6: Scenario: Some determinable business situation 7: Given some precondition 8: And some other precondition 9: When some action by the actor 10: And some other action 11: And yet another action 12: Then some testable outcome is achieved 13: And something else we can check happens too 14: 15: Scenario: A different situation 10
• 11.
  • First linestarts the feature. • Lines 2-4 are unparsed text, which is expected to describe the business value of this feature. Line 6 starts a scenario. • Lines 7-13 are the steps for the scenario. • Line 15 starts next scenario and so on. 11
• 12.
  .Feature • The scenariois then divided into three parts. 1. The ‘Given’ part describes how the system should be prepared before the testing. This is the setup for the system. 2. The ‘When’ part describes how the system should be used. This is the execution part of the example. 3. The ‘Then’ part is where you verify that the system is in the expected state. This is the assert part of the test. 12
• 13.
  TDD & BDD •Test driven development The word “driven” here refers to the way of writing the tests first, then the code to make the tests pass. Test driven development is more of a developer oriented approach, a more low level way of doing things. • Behaviour driven development In BDD on the other hand, the tests are described in a natural language, which makes the tests more accessible to people outside of development or testing teams. It can describe the functionality as specifications do. 13
• 14.
  Cucumber and BDD •While Cucumber can be thought of as a “testing” tool, the intent of the tool is to support BDD. This means that the “tests” (plain text feature descriptions with scenarios) are typically written before anything else and verified by business analysts, domain experts, etc. non technical stakeholders. The production code is then written outside-in, to make the stories pass. 14
• 15.
  Installation(1/2) • In orderto use Cucumber within some frameworks or specific environments : • install for Ruby on Rails • install for Jruby and Java • install for IronRuby and .NET 15
• 16.
  Installation(2/2) Cucumber-jvm JUnit class that will connect the feature to a runner, Cucumber-html.jar Jchronic.jar Cucumber-core.jar Cucumber-java.jar Cucumber-junit.jar 16
• 17.
  Running Cucumber • Thereare quite a few ways you can run Cucumber. It depends on what programming language you are using and also what build tool you are using (if any). • Command Line • Rake • Maven • Ant • JUnit • IDEs (Eclipse, IDEA) 17
• 18.
  Demo Application Src/test/java Src/main/java HelloSteps.Defjava RunCukesTest.java Hello.java .features 18
• 19.
  Conclusion Try to useCucumber 19
• 20.
  Thank You 20