BDD (Behavior Driven Development) has been a buzz word for quite a while. My question is whether to adopt it or not.
I’m gonna start by describing what you can do using this approach. Using ‘Cucumber’ (http://cukes.info/) to illustrate the picture; which is quite amazing for someone not familiar test automation. Then I’ll raise some questions.
Cucumber is a software package used for test automation in BDD, originally written in Ruby but ported to other platforms like Java. The idea behind it is to specify tests on natural language that are subsequently translated into automated tests. Allowing a common ground for Business and Functional teams.
First you start with a test case (Feature File). Simply a text file, with some well known keywords. The example bellow is for testing the IKEA search page for e.g.
I’m gonna start by describing what you can do using this approach. Using ‘Cucumber’ (http://cukes.info/) to illustrate the picture; which is quite amazing for someone not familiar test automation. Then I’ll raise some questions.
Cucumber is a software package used for test automation in BDD, originally written in Ruby but ported to other platforms like Java. The idea behind it is to specify tests on natural language that are subsequently translated into automated tests. Allowing a common ground for Business and Functional teams.
First you start with a test case (Feature File). Simply a text file, with some well known keywords. The example bellow is for testing the IKEA search page for e.g.
That’s right, with Cucumber you can test web UI, webservices, REST interfaces… well everything you can invoke from Java.
In this case we have to use a special driver to accomplish web-browser tests form inside Java: Selenium webdriver (www.seleniumhq.org). The principle is that you can use this (jar) package to invoke web-browser actions from inside your test suite. Selenium also provides a plugin for Firefox were you can record the actions you want to automate:
In this case we have to use a special driver to accomplish web-browser tests form inside Java: Selenium webdriver (www.seleniumhq.org). The principle is that you can use this (jar) package to invoke web-browser actions from inside your test suite. Selenium also provides a plugin for Firefox were you can record the actions you want to automate:
With a simple export action you get the Java code that implements this interaction (open the URL, type the search expression and hit the search button).
Then ‘simply’ copy/paste this code inside your JUnit test and link it to the generated stubs from the feature file. You may notice that I skip some steps, but for the purpose of this article I’m just going to sketch the components:
I just forgot to mention that the Cucumber Stub files are generated automatically the first time you run the Junit test suite. After that, when you run your test suite from inside Eclipse (for e.g.), the webbrowser is open an you can watch the test execution.
(It seems complicated, but trust me I managed to implement this in a morning and by the end of the day I already had webservices on the mix.)
Moving forward, you may want to create a Maven-like project in order to run the tests from a CI (Continuous Integration) Tool like Jenkins. Just replace the webdriver by a headless one, and quite amazingly you can run your test suite every day and have report emailed to your inbox.
Questions:
The questions arise when you try to implement this approach on an organization with live applications. The first stage will be to build a framework to handle each application, followed by procedures for test creation and in the end come up with a validation/issue process.
In my opinion BDD, in order to be effective, has to start when the application under test starts being developed. This kind of test methodology should be aligned and a part of continuous integration, from the start. The responsibility of automation should be inside the development team, as it takes its inputs from the business.
Other concern is the kind of applications under test. For custom development this approach fits as a charm, however for commercial packages (SAP, Siebel…) the cost of building an action library is too high and will be deprecated by the next product release. Here COTS (Commercial of the Shelve) products will prove to be much more effective.
Share your thoughts/experience with Cucumber
(It seems complicated, but trust me I managed to implement this in a morning and by the end of the day I already had webservices on the mix.)
Moving forward, you may want to create a Maven-like project in order to run the tests from a CI (Continuous Integration) Tool like Jenkins. Just replace the webdriver by a headless one, and quite amazingly you can run your test suite every day and have report emailed to your inbox.
Questions:
The questions arise when you try to implement this approach on an organization with live applications. The first stage will be to build a framework to handle each application, followed by procedures for test creation and in the end come up with a validation/issue process.
In my opinion BDD, in order to be effective, has to start when the application under test starts being developed. This kind of test methodology should be aligned and a part of continuous integration, from the start. The responsibility of automation should be inside the development team, as it takes its inputs from the business.
Other concern is the kind of applications under test. For custom development this approach fits as a charm, however for commercial packages (SAP, Siebel…) the cost of building an action library is too high and will be deprecated by the next product release. Here COTS (Commercial of the Shelve) products will prove to be much more effective.
Share your thoughts/experience with Cucumber