Is there any difference in the implementation of Behavior Driven Development in the case of a Rich Client Application (or Rich Internet Application) ?
BDD's primary goal is communication. In that regard, there are no differences. However I see the differences in the outside-in implementation techniques.
There is no need to test the application through the GUI to make sure the specifications (customer acceptance criteria) are met.
We are back to those days where libraries to handle GUIs were so powerful and nice for both, developers and users. This time with 10+ years experience in agile testing and all kind of testing tools.
If I use Cucumber (I am using SpecFlow right now), my step definitions do not hit the UI. They just load the page and access the Business API (test API).
- [Given(@"^I start a new task$")]
- public void GivenIStartANewTask(int minutes)
- var browser = ScenarioContext.Current[browserKey] as IWebDriver;
- var navigation = browser.Navigate();
- var invoked = (string)js.ExecuteScript(
- "return app.startNewTask();");
- // making sure the Business API got the call
- describe "LiveTeamApp: the team productivity application", ->
- beforeEach ->
- loadApp(appAddress, initTests)
- describe "the tasks management system", ->
- it "counts the time consumed by every task", ->
- waits two.seconds
This is Jasmine plus Chai's syntactic sugar (should).
This scenario is actual code from my application LiveTeamApp.com, which has been developed entirely following this process (please check it out with your team, I believe you will like it 😉
Notice how I am writing a programmatic interface (the test adapter) to talk to the application with the language of the domain.
For asynchronous cases, I am writing a small fluent API called Flas, which uses Gherkin to encapsulate blocks containing jQuery ajax requests. The Given-When-Then blocks scope asynchronous calls so that every block is executed once the calls have finished.
For more complex scenarios where I need several instances of the application at the same time (to design and test how users interact with each other), I am using CasperJS. This the case of LiveTeamApp's chat service, where users can chat with each other and also chat with the whole team. The acceptance criteria has been written with CasperJs to open several browsers and use the programmatic API from all of them to interact. Again, no need to hit the GUI in those acceptance tests.
If you want to learn more and practice the technique, I encourage you to attend to my workshop. In the workshop you practice the whole BDD cycle, from the specifications workshop to the views implementation. See more information about the workshop in this post.
I won't repeat the great lessons you can read in The Cucumber Book which is a must-read. Even if you are not using Cucumber, Matt's and Aslak's book is fantastic to learn BDD.
The other books I would expect my readers to read before, are the ones by Gojko Adzic on Briding the Communication Gap and Specification by Example 🙂