Hi folks,
I’m writing some scripts to integrate our cucumber features with stories
stored in a wiki, and I’m hoping to use cucumber’s parser to parse the
features rather than doing it manually. (I don’t really care about the
feature contents much, just scenario titles and tags)
I’ve worked out how to parse the features:
Cucumber.load_language(‘en’)
features = Cucumber::Ast::Features.new
parser = Cucumber::Parser::FeatureParser.new
feature_files = Dir["#{FEATURE_DIR}/**/*.feature"]
feature_files.each do |f|
puts "parsing feature file #{f}"
features.add_feature(parser.parse_file(f))
end
But now I’m digging in to the whole ast visitor thing, and it’s getting
quite complex to do stuff with the features once I’ve parsed them.
I’m sure I can work this out myself, given time, but I was wondering if
there are any code examples out there to save me some of the
time/effort?
Anyone else tried parsing features like this from outside Cucumber
itself?
Hmm - on digging further, I might be better off writing a custom
formatter
as described at http://wiki.github.com/aslakhellesoy/cucumber/custom-formatters, and
just
invoking cucumber with --dry-run and my formatter… Though as I want
to
use the html formatter to format steps for insertion into the wiki, I’ve
still got some work to do
In case anyone followed this: I got everything working pretty nicely -
now I
have a cucumber formatter that automatically updates a confluence wiki.
I still have to cover some bits like table outputs and the like, but the
basics are pretty nice - I use cucumber to parse the features and create
a
wiki page per feature file with the (complete) feature, and I also check
for
scenarios with tags like “@story-blah”, and update the corresponding
story
page in the wiki.
I’m not sure this stuff is much use generally, it’s pretty tightly
coupled
to how we have our wiki set up - but I’m happy to share the (messy) code
if
anyone is interested.
I should clarify what might not be obvious from the code:
This builds two sets of pages in the wiki:
Features, which are basically just a dump of the features files into
wiki
format, added as children of the main “Features” page (confluence lets
you
have parent/child relationships, which is great for this sort of thing -
no
need to create an index page)
Stories, which are our user stories; these are written by hand, and
the
script looks for story tags on each scenario, and if it finds a matching
story in the wiki, it inserts the scenario into that wiki page (and
links it
back to the matching feature page).
So, for example, I might have features:
Feature: top level tabs (in tabs.feature) @story-f-001@story-f-002@qa
Scenario: visit the foo tab
Given I am viewing the main page
When I navigate to the “Foo” tab
Then I should be on the “Foo” panel
Feature: foo wrangling (in foo.feature) @story-f-001@qa
Scenario: display all foos
Given I am viewing the “Foo” panel
When I select “view all”
Then I should see all foos in the system
Running “cucumber --dry-run --format WikiFormatter” will build new wiki
pages “tabs” and “foo”, and if there is a story page called “foo-1” it
will
add the tagged scenarios to it as well. (in a special “qa” section in
this
case)
story in the wiki, it inserts the scenario into that wiki page (and links it
back to the matching feature page).
Sounds like an excellent example of adaptation for a team that has
already
settled on an external tool to manage the development process and
communication in general. Cool stuff!
Aslak
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.