Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Bdd with Cucumber and Mocha

7,307 views

Published on

Presentation on Behavior Driven Development with Cucumber and Mocha

Published in: Software

Bdd with Cucumber and Mocha

  1. 1. hugeinc.com info@hugeinc.com 45 Main St. #220 Brooklyn, NY 11222 +1 718 625 4843 Mar 12, 2014 BDD
  2. 2. BDD Node with MochaSelenium with Cucumber
  3. 3. • Agile Manifesto • Evolutionary Development and Design • BDD introduction • BDD Philosophy and Implementation • BDD with Selenium & Cucumber • BDD with Node & Mocha • BDD in Agile Topics Covered .
  4. 4. • Composed by heavy hitters in the software industry in Snowbird, UT in February 2001. • Included the folks backing methodologies such as Scrum, XP, Crystal ,Feature driven development, etc. • Big names included such as Martin Fowler, Robert C Martin( Uncle Bob), Alistair Cockburn, Ken Schwaber etc. Agile Manifesto .
  5. 5. Agile Manifesto - Continued . • Continuous Delivery & Integration o Welcome changing reqs o Deliver working software frequently o Involve biz and developers throughout the project o Build projects around motivated folks o Communication should be face to face o Primary metric of progress is working software o Simplicity is essential o Self organizing teams o Periodic retrospectives
  6. 6. Continuous Delivery & Integration . You can't just ask customers what they want and then try to give that to them. By the time you get it built, they'll want something new. - Steve Jobs
  7. 7. What Agile says... . Continuous Development and Testing. Deliver features rather than modules. Only focus on high-value features Strong emphasis on testing. Adapt to faster feedback Strong emphasis on continuous integration. Once all software is ready for delivery, all tests should pass. A unique way to address modern challenges in software development.
  8. 8. Automation is the key .
  9. 9. .
  10. 10. Technology Facing . These automated tests are written and maintained exclusively by developers. There are three kinds of tests that fall into this category ● Unit Test ● Integration / Component Test ● System / Deployment Test
  11. 11. Test Driven Dvlp (TDD) Philosophy . The basic tenets are developing and implementing Tests before writing a line of code Tests will and must fail up front Code is developed after the test is developed. A unique idea that is still foreign to many developers This does not imply that we must use an agile development process.
  12. 12. Business Facing . The tests in this quadrant are more commonly known as Functional or Acceptance Tests. Acceptance testing ensures that the acceptance criteria for a story are met Acceptance tests can test all kinds of attributes of the system being built, including functionality, capacity, usability, security, modifiability, availability Acceptance tests are critical in an agile environment because they answer the questions, “How do I know when I am done?” for developers and “Did I get what I wanted?” for users
  13. 13. Why Acceptance Testing essential? . Many developers believe that unit test suites created through test-driven development are enough to protect against regressions Acceptance tests are business-facing, not developer-facing. Unit tests are an essential part of any automated test strategy, but they usually do not provide a high enough level of confidence that the application can be released. The objective of acceptance tests is to prove that our application does what the customer meant it to, not that it works the way its programmers think it should.
  14. 14. Acceptance Testing .
  15. 15. Executable Specifications . As automated acceptance testing has become more central to the continuous delivery, practitioners have realized that automated testing is not just about testing. Rather, acceptance tests are executable specifications of the behavior of the software being developed. This realization has spawned a new approach to automated testing. Behavior Driven Development
  16. 16. What is BDD? . “Behavior-driven development is about implementing an application by describing its behavior from the perspective of its stakeholders”. “It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters.”
  17. 17. BDD is derivative . BDD is second generation agile methodology. Its an evolution to TDD. One of the core ideas of behavior-driven development is that your acceptance criteria should be written in the form of the customer’s expectations of the behavior of the application. It should then be possible to take acceptance criteria thus written, and execute them directly against the application to verify that the application meets its specification
  18. 18. BDD in easy steps .
  19. 19. Application breakup .
  20. 20. What’s in a story? . A story is a unit of delivery Story -28 Cash Withdrawal from ATM As a active bank account holder I want to withdraw cash from Bank ATM
  21. 21. Agree on “done” . Define scope using scenarios. Feature: Cash Withdrawal from ATM As a active bank account holder I want to withdraw cash from Bank ATM Scenario 1 – Cash Withdrawal with Sufficient amount Given I have 100$ in account When I withdraw 50$ Then Machine gives me 50$ Scenario 2 – Cash Withdrawal with In-Sufficient amount Given I have 10$ in account When I withdraw 50$ Then Machine says insufficent amount.
  22. 22. Tools and Frameworks . Stories & Scenarios: Cucumber, JBehave, Mocha, Concordian, Twist Implementation: Selenium, Junit or TestNG
  23. 23. Cucumber Framework . Cucumber is the most popular tool is writing Scenarios in style of Tests which can be shared with Non-Tech people. It alters the traditional, boring, very large requirement documents into clean, understandable English syntax feature files which execute itself. In short cucumber delivers executable Delivery document. It uses very simple Gherkin language to define the scenarios.
  24. 24. Cucumber Framework . Cucumber Features is nothing but list of executable steps. There are 3 major types of steps. Given – When – Then - Given some initial context - When an event occurs - Then ensures some outcomes.
  25. 25. Automate the scenarios in Java with Cucumber . Make each step executable @Given(“I have 100$ in account”) public void createAccountWithBalance() { } @When(“I withdraw 50$”) public void makeWithdrawAction() { } @Then(“Machine gives me 50$”) public void dispenseTheCash() { }
  26. 26. Automate the scenarios in Java . Make each step executable @Given(“I have 10$ in account”) public void createAccountWithBalance() { } @When(“I withdraw 50$”) public void makeWithdrawAction() { } @Then(“Machine says insufficient amount”) public void withdrawlError() { }
  27. 27. Additional feature of cucumbers . Before: @Given(“I have 10$ in account”) public void createAccountWithBalance() { } After: @Given(“I have (d+)$ in account”) public void createAccountWithBalance(var amount) { } Before: @Then(“Machine says ‘Insufficient amount’”) public void withdrawlError() { } After: @Then(“Machine says (.*)”) public void withdrawlError(var message) { }
  28. 28. Automation is the key . Scenarios become acceptance tests which become regression test ...and documentation Examples become code tests …and documentation
  29. 29. Test Automation Tools . • Quick Test Professional By HP • Rational Functional Tester By Rational (IBM Company) • Silk Test By Borland • Test complete By Automated QA • QA Run (Compuware ) • Watir ( Open Source) • Selenium ( Open Source) • Sahi (Open Source)
  30. 30. Test Automation Using Selenium . Selenium is a robust set of tools that supports rapid development of test automation for web-based applications. Selenium provides a rich set of testing functions specifically geared to the needs of testing of a web application. Selenium operations are highly flexible, allowing many options for locating UI elements and comparing expected test results against actual application behavior.
  31. 31. Selenium Framework Features . • Supports Cross Browser Testing. The Selenium tests can be run on multiple browsers. • Allows scripting in several languages like Java, C#, PHP and Python. • Assertion statements provide an efficient way of comparing expected and actual results. • Inbuilt reporting mechanism.
  32. 32. Selenium Driver . • Selenium driver is the most important point of function in writing Selenium Tests • Driver can perform many functions like • Open a page • Find elements ( By Id, class or CSS Property) • Wait for a page load or action • Fill the text boxes • Click the Buttons, URLs • Hover on elements Over all Selenium driver is the one with whom everyone has to deal mainly. Lot of common functionality has been implemented somewhere is other tests. There is very good online community support and documents for any queries or questions.
  33. 33. Cucumber Feature : Code Example . @CompareHappyPath Feature: Compare Vehicles As a user, I can compare a Lexus trim to other vehicle trims Scenario: User can successfully compare one vehicle to another Given user starts Compare flow on a large viewport When they select the IS model When they select the IS 250 AWD trim When they add a competitor trim Then ensure the compare vehicles button appears
  34. 34. Selenium Code Example in Lexus . private String startUrl = "/web/compare"; @Before("@CompareHappyPath") public void setUp() throws Exception { logger.debug("Start Compare Happy Path..."); } @After("@CompareHappyPath") public void tearDown() { if (driver != null) { } driver.quit(); } @Given("user starts Compare flow on a (.*) viewport") public void startHappyPath(String viewportSize) { this.openPage(startUrl); assertTrue(StringUtils.endsWith(driver.getCurrentUrl(), startUrl)); }
  35. 35. - NodeJS testing frameworks BDD: Mocha **, Vows*, Jasmine*, Cucumber * TDD: Expresso Both: Mocha ***, Chai * - Mocha is primarily BDD. TDD is a special mod of it. From (1) https://nodejsmodules.org/tags/testing (2) https://nodejsmodules.org/tags/bdd (3) https://nodejsmodules.org/tags/tdd In NodeJS world
  36. 36. NodeJS Framework . Set the requirements: ● Requirement 1: Landing page functionality a. 1.1 Need to see text on the landing page. b. 1.2 Need to see the link to the login page. ● Requirement 2: Login page functionality a. 2.1 Need to see text on the login page. b. 2.2 Need to be able to login with user/email “TEST”/”TEST”. … etc.
  37. 37. NodeJS Framework .
  38. 38. NodeJS Framework . TDD implementation very similar to BDD implementation
  39. 39. NodeJS Framework . Expected Output: Expected Failure Output:
  40. 40. Ideal qualities of Tests . • Decisive – Test should be human communication filter. It should determine success/failure of a program and each time it should help to advance to next level. • Complete Test should read like a story. It should contains all the information it needs to run correctly with a given test harness and work artifact under test. • Valid – produces a result that matches the intention of the work artifact under test • Repeatable always gives the same results if the test harness and the artifact under test are the same i.e. Is deterministic • Isolated is not affected by other tests run before it nor does a test affect the results of tests run after it • Automated requires only a start signal in order to run to completion in a finite amount of time
  41. 41. Quotes . If it's worth building, it's worth testing. If it's not worth testing, why are you wasting your time working on it?
  42. 42. BDD benefits . • It produces the software that matters. • Requirement becomes easy to understand and communicate. • It promotes tangible stakeholder value in software solution. • Provides detailed (executable) specifications • Provides concrete evidence that your code works • Requires developers to prove it with code • Provides finely grained, concrete feedback (in mins) • Supports evolutionary development • Defects after deployment are rare and non critical. Much difference than Legacy way of development. BDD is a step in that direction
  43. 43. BDD Costs . • Cost of learning curve. Initial dip in productivity, but quality deliverable starts from day one. • Maintaining acceptance tests over the long term requires discipline. • Continuous refactoring as new acceptance criteria comes. • Need to deal with Social barrier. • Slow performance At the end its subjective decision either its costly or not costly. The great ROYAL FATE….!
  44. 44. Myth . Myth: No one knows TDD/BDD. Otherwise it would be everywhere. Answer: Not true…! Large portion of developers has been exposed to TDD since last 5 years. Myth looks true due to very less adoption ratio. And the one of the reason ( Out of many is) social barrier. I see only two class in my Team. And I am a programmer not QA. I cannot write tests.
  45. 45. Who owns Acceptance Tests? .
  46. 46. Agile Developer .
  47. 47. Agile Developer . • Agile programmers are pros because they take things like software quality very seriously. • The best are passionate testers who take pride in their work and are always looking for an edge in writing higher-quality code. • To that end, there are certain things agile programmers do when regularly creating high-quality, production-ready software. • They write lots of tests and will often use tests as a means of driving out their designs. • They are continuously designing and improving the architecture of their software as they go. • They make sure the code base is always in a state of production readiness and ready to deploy at a moment’s notice.
  48. 48. Agile Tester .
  49. 49. Agile Tester . • Agile testers know that although it’s one thing to build it, it is another to know it works. • Agile tester will insert themselves into the agile project early, ensuring that success for user stories gets defined up front and that when working software is produced, it works. • Agile tester work closely with developers, helping with test automation, looking for holes, and doing extensive exploratory testing by trying to break the application from all possible angles. • Agile Tester have in mind the big testing picture and never lose site of load testing, scalability, and anything else the team could be doing to produce high- quality software.
  50. 50. Lexus Experience ● We used traditional model : Acceptance tests are the responsibility of the testing team. ● The test team was always at the end of the chain of development, so our acceptance tests spent most of their lives failing. ● This is not a trivial problem. Acceptance tests are often complex. ● We changed the ownership of the automated acceptance tests. 1. Happy Path 2. Alternative Path 3. Sad Path
  51. 51. Experience . “All right… we know what BDD is and understand the importance of Tests but you know… one day tests started to fail and then one day we got override of it.” This nonsense seems to be common in across the industry. If test is not running, means my program isn't running. Don’t deliver it. In practical, this happens as programmers faces lot pressure apart from programming. They can’t convenience non-Tech leads about the process and quality. So the first and most important thing in BDD/TDD is Support from Leads.
  52. 52. Acceptance BDD … to overcome above problem . • Acceptance Business Driven Development (ATDD) is a practice in which the whole team collaboratively discusses acceptance criteria, with examples, and then distills them into a set of concrete acceptance tests before development begins. • It’s the best way I know to ensure that we all have the same shared understanding of what it is we’re actually building. • It’s also the best way known to ensure we have a shared definition of Done.
  53. 53. Experience … Continued . BDD is not only to write Acceptance Test first before Code. Its philosophy and very highly articulated practice , it needs time to understand, digest and make it in practice in day to day work. Next question… Are we following BDD in Lexus? I don’t think so, but we should try. I think … the day when Programmer thinks first about Test before Code implementation and Implement functionality through the window of acceptance criteria compiled by Analysts and QA then we would be on path of BDD.
  54. 54. Questions?… Comments?...
  55. 55. hugeinc.com info@hugeinc.com 45 Main St. #220 Brooklyn, NY 11222 +1 718 625 4843

×