/blog/2014/05/segue-steps/ Thinking through writing... on innovation, business, technology and more Sun, 24 May 2015 01:54:00 +0000 hourly 1 http://wordpress.org/?v=4.0.7 /blog/2014/05/segue-steps/comment-page-1/#comment-3234 Sun, 24 May 2015 01:54:00 +0000 /blog/?p=556#comment-3234 BDD and the tools were kind of scrappy for a while, but over the last 18 months, the pace, adoption and improvements have been ever-increasing.

]]> /blog/2014/05/segue-steps/comment-page-1/#comment-3233 Sun, 24 May 2015 01:52:00 +0000 /blog/?p=556#comment-3233 (Very) belated comment, but Gherkin is very flexible. Common misunderstanding is it’s not, but if you look at it as code (which is what it is), it becomes a programming type exercise. It’s just another layer of abstraction (the next layer up from the acceptance test code). Multiple “should”‘s for example, can be treated as an array, in Gherkin. Common steps can be bundled as one Gherkin statement, when specifying complete steps are unnecessary. Forms can be processed as tables, rather than lengthy “I fill in this with that”. Developers appreciate the well-structured scenarios, as it guides them better too. BDD a commitment thing, and so is the Gherkin – it does take time to build up, but you end up with a suite of executable natural language features, and strict QA. It kept a good project momentum going too. The Gherkin art is in keeping it readable, but not letting it stand still. And of course documenting, and alerting others to new Gherkin available to use. The out-the-box Gherkin is a bit mundane, but picks up on many common steps – we are not as original as we think. Where the value becomes apparent, is as the test application grows, and more custom Gherkin(DSL) is created. The value even better demonstrated when integrated with the app it is testing. Becomes it’s own development/testing machine

]]> /blog/2014/05/segue-steps/comment-page-1/#comment-3212 Mon, 05 May 2014 13:23:00 +0000 /blog/?p=556#comment-3212 Great trick. Thanks for the post

]]>