Gherkin DSL for testcase description and automation

[Brendan Donegan]

On 10/12/11 13:43, Charlie Kravetz wrote:
> On Sat, 10 Dec 2011 12:35:21 +0200
> Руаньяк <roignac at gmail.com> wrote:
>
> > Hi,
>
> > 2011/12/10 Alex Lourie <djay.il at gmail.com>:
> >> I have the following questions:
> >>
> >> 1. How long does it take to write something like that for someone
> who's not
> >> a programmer and have no idea about Cucumber or unit testing in
> general?
> > I guess, it should not take much time. The only rule to be followed is
> > 'Action after When, Expected result after Then, Concatenation is And'.
> > Maybe, someone inexperienced in Gherkin could measure the time and
> > post results here? For instance, this conversion of DesktopWhole case
> > took about 10 min. for me.
>
> As someone completely ignorant of Gherkin, it took me over 10 minutes
> to read through this test case. In reading through, I attempted to
> picture most of the steps, and found the flow doesn't work right here.
> I test a lot of images, and I test images daily. This test is much too
> specific. Also, it does not read well, from an english language user.
> It reads much like something written by lawyers reads to the lay person.
I think this a perfect analogy. Yes, it is still English and yes, if you
have certain background then they are perfectly readable.

Let me just say thanks to Vadim for introducing us all to Gherkin - I
know that it's something I'll be taking a closer look at in future, but
I think the prerogative for the near future has to be to fix the flaws
in the current test cases, those being that they have out-of-date
instructions and often lack any sort of expected result, as well as a
clear objective - and the fact is that apart from these problems the
current test cases are pretty much in ISTQB form so the most
straightforward way to complete this exercise is going to be to continue
with that.
>
> I don't think I could actually write such a test case, in less than at
> least an hour, and perhaps that is not enough enough time.
>
>
> >> 2. How would one execute this in LiveCD environment?
> > Manual testers may use this as a usual test case. Whenever bug
> > appears, the tester may break the instruction, e.g.
> > ---
> > When I double click 'Install Ubuntu' icon
> > Then Ubuquity starts  #here we can check main window etc.
>
> > Result: Ubiquity crashes with error 'ImportError:..."
> > ---
> >> 3. Is it possible to run something like that in automated VM
> environment?
> > Yes, as there is nose framework plugin Freshen (see
> > https://github.com/rlisagor/freshen), which generates xUnit reports
> > from feature files. Another option is Lettuce (see
> > https://github.com/gabrielfalcao/lettuce)
>
> > All steps should be defined (using ldtp) in definition file(s), which
> > contain the actual automation code for each step, something like this:
> > -- from steps.py --
> > @step("I double click 'Install Ubuntu' icon"):
> > def double_click_on_ubuntu_icon:
> >  ltdp.double_click("btnInstallUbuntu");
>
> > Then, using steps definitions and scenarios, automation suite will do
> > the following:
> > a) create a virtual machine
> > b) start up from live cd
> > c) fire up LDTP server on virtual machine
> > d) connect to LDTP server and execute steps from scenarios
> > e) collect xUnit results and post them to CI (Jenkins)
>
> > I haven't tried this at home, so we should contact automation guys, as
> > they are using something similar for automation daily precise images
> > --
> > Vadim Rutkovsky
>
>
> While I realize that many of you are degree holders, community members
> as a rule are users who decided to get involved in helping their
> favorite software. For some, this is a way to give back for the ability
> to use the software.
>
> For the common user, these types of tests are not actually something
> they can follow easily. The test cases as written, using steps, are
> usable by all of us.
>
>