Cucumber Intro

from: https://matthewdaly.co.uk/blog/2012/11/03/testing-php-web-applications-with-cucumber/

“What’s so great about Cucumber compared to other acceptance testing solutions?

  • Cucumber scenarios are written using Gherkin, a simple syntax that makes it easy for customers to set out exactly what behaviour they want to see. Far from being tedious requirement documents, these set out in a simple and intuitive way what should happen once the application is complete. By requiring customers to think carefully about what they want and get it down in writing, you can ensure the customer has a good idea what they want before you write any code, making it much less likely they’ll turn around afterwards and say “No, that’s not what we want”. This, more than anything, is for me the true power of Cucumber – it allows customers and developers to easily collaborate to set out what the web app will do, and gets you automated tests into the bargain as well.
  • Because Cucumber is packaged as a Ruby gem, it’s easy to install it and any other Ruby modules it may require.
  • You can use Capybara to test your web app. Capybara is a very handy Ruby gem that allows you to easily interact with your web app, and it allows several different drivers to be used. If you don’t need JavaScript, for instance, you can use Mechanize for faster tests. If you do, you can use selenium-webdriver to automate the browser instead, and it will load an instance of Firefox and use that for testing.
  • It can also be used for testing RESTful web services. HTTParty is another handy Ruby gem that can be used for testing an API.”

Benefits:

  • common understood language using Gherkin
    • As you collaborate and clarify scenarios with the team and business owners, you also know that half of your automation effort is already done and even before coding begins.
  • Integrates with many tools and systems: Git, Jenkins, Selenium, Saucelabs, Jira, Confluence, so it bridges the gap between DEV and QA or Testers,…
    • It’s been integrated with GitHub, in order to follow the same structure and process as developers. This way “Tests are Tests” and therefore all reside in the same infrastructure. Everyone on the team can collaborate on all tests (unit/integration/… to functional/end-to-end tests).
    • you can have coverage and test reports in Jenkins, you can plugin the scenarios in Confluence to have living documentation.

As with any automation testing frameworks, maintenance and keeping tests up to date is key.

But one BIG plus is that the Scenarios written in Gherkin mentioned above are ALSO your living documentation of what the feature does, so you never have to worry about cleaning old test cases or wondering if a test is still valid. 🙂 and you can (with the help of plugins), display the features and scenarios and test results in a wiki.

AND… it fits in very well in AGILE!

Here is a sample Agile workflow with some tooks that works;

  1. Stories are presented and defined in JIRA
  2. Stories get clarified using Gherkin / Cucumber Scenarios – Given/When/Then
  3. Gherkin scenarios are then linked to/from GIT repo for version control
  4. Stories are assigned to dev and fine-tuned
  5. Scenarios can be fine-tuned in GIT as well
  6. Automating the steps of the Scenarios can begin!
  7. Automation tests pass or fail depending on progress of development of code (Git hooked up with Jenkins, you can also automate the process of running the tests at intervals or date/time or when new code is pushed)
  8. When stories is done, your automation tests pass and you are also done. Wahoo!
  9. automated steps can then be reused for future scenarios, so you don’t have to repeat.
  10. If a scenario needs to change, you change existing scenario without having to rewrite a whole new test case or automation script.

NOTE:

Testing works best with a two-layer combination of end-to-end tests (e.g. Cucumber) that prove you’re building the right thing, and low-level unit tests (e.g. RSpec) that prove you’re building the thing right. These tests are for different audiences and so suit different tools.

 

excerpt from: https://cucumber.io/blog/2014/09/10/when-cucumbers-go-bad

Acceptance Tests Don’t Have to Be End-to-End Tests

Just because you’re using Cucumber, doesn’t mean you have to run an end-to-end test. Cucumber is for documenting behaviour that non-technical people care about. If you know that behaviour is implemented in a single class in your application, then why fire up a browser? You can hit that class directly.

…

Writing Cucumber scenarios together is a great way to build a team’s share understanding of the problem domain. When you have a scenario written, and everyone agrees you want that behaviour, it’s time to ask an important question:

What’s the best way to test this scenario?

If the technical perspective says that you can test this behaviour with a fast unit test, yet the business folks want it to remain as a Cucumber scenario, you have three options:

  1. Suck it up, and write another end-to-end test
  2. Wire up an acceptance test that connects directly to your domain model (see above)
  3. Convince the business folks to trust you, and write it as a unit test

Archives

Categories

Recent Posts