Hi all, 2011/12/9 Alex Lourie <djay...@gmail.com>: > > > On Fri, Dec 9, 2011 at 12:41 PM, Brendan Donegan > <brendan.done...@canonical.com> wrote: >> >> Not sure I buy some of the criticisms of the ISTQB definitions, but it's >> certainly true that Gherkin encodes the tests in such a way as to make >> it possible for tools to parse them, whereas perhaps ISTQB definitions >> don't have that. I do think the language ends up looking slightly weird >> for manual testers who may not have that much experience with the >> software though. Here's a weakness, at least in the definitions given >> below: >> >> Scenario: TC_CAL-002: Calculate sums >> Given Calculator is in Basic mode >> When I input "1+1" >> And I calculate result <- How? >> Then Result is "2" <- Where? >> And No error occurs <- Where does the error not occur? Yes, a poorly written scenario here. Anyway, these steps can be re-written in any possible way. The most important parts are keywords - Given, When, Then, And, But etc. - and step consistency (mostly for automation). We can even use bzr+launchpad to store testcases and Launchpad Code Merge for testcase review and merge. That would be great to find/develop a system, which will present the tests in Gherkin in cool sexy-looking way, which will be at the same time a) easy for manual testers, b) useful for automated testing team.
>> I will concede that those things are probably rectifiable though. We >> just need to acknowledge that given a.) time and resource constraints >> and b.) the very nature of certain tests, we won't be able to automate >> everything and whereas ISTQB provides a definition which is probably >> easier to understand for the manual tester but not so much for tools, >> Gherkin DSL provides one that is easier for tools to understand but >> maybe vulnerable to providing definitions that are more difficult for >> manual testers. >> > > So, in fact, we kind of need to decide who should we cater more with the > test cases - manual > testers or automatic ones? I think we need to handle manual ones now, and > try to move as much > as possible for automation later. So ISTQB definition would get my +1 for > the nearest future. I guess, Gherkin tests are not that hard to understand and they have another feature - they are much easier to create new ones (simply as they use less symbols ;) If we use Gherkin DSL for both manual and automated tests, we will avoid converstion from manual tests to automated unit-test - and this takes a lot of time, as I've been developing some tests for Mago recently. Simply, automation team just have to write actions for each step, for instance: @Given('Calculator is in (.+) mode') def switch_to_mode(mode): <code for switching Gcalc mode> @When('I click "(.+)" button') def click_button(button): <code for clicking "button"> etc. etc. > >> >> It also seems that it's background is unit test generation and I'd be >> curious to see what a larger test case written in this syntax would look >> like. >> > > And so would I :-) I havn't written many tests using Gherkin, here are some Mago tests rewritten - lp:~roignac/+junk/lettuce_experiment -- Vadim Rutkovsky -- Ubuntu-qa mailing list Ubuntu-qa@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-qa