It’s time for some new features again. Output is now much better since
you
can use diffing, tweak
the output colours and get the full --backtrace if you want. Managing
your
support/* files became
a little easier since they are now always loaded before the step
definitions. Life became easier
for Windows users in Norway (and other countries using unicode in the
features). Plus several other
bug fixes.
One of the coolest new feature is Scenario Outline, implemented by
Joseph
Wilk with lots of great
input from several others. It’s not yet documented in the Wiki, but you
can
read about it here:
http://rspec.lighthouseapp.com/projects/16211-cucumber/tickets/57
Full release notes on GitHub:
http://github.com/aslakhellesoy/cucumber/tree/v0.1.13/History.txt
Cheers,
Aslak
On 20 Dec 2008, at 21:02, aslak hellesoy wrote:
It’s time for some new features again. Output is now much better
since you can use diffing, tweak
the output colours and get the full --backtrace if you want.
Managing your support/* files became
a little easier since they are now always loaded before the step
definitions. Life became easier
for Windows users in Norway (and other countries using unicode in
the features). Plus several other
bug fixes.
What’s this about support/* files? Is there some convention emerging
around structuring the features directory that I’ve missed?
It would be cool to hear more from people about how they do this. I
have a feeling our structure at work could be better, but I’m not sure
what other models are out there.
FWIW, we do this
features
/logged_in_user.html
a_feature_that_requires_authentication.feature
…other features specific to the ‘user’ role
/steps.common
env.rb
… other steps (typically Givens) that work beneath the UI
/steps.html
webrat_steps.rb
… other steps that work through the UI
/visitor.html
a_feature_that_anonymous_users_can_enjoy.feature
…other features specific to the ‘visitor’ role
The idea behind the .common / .html split was when we also had WATIR
steps (which we’ve abandoned for the time being) and we wanted to keep
a distinction between features / steps that worked with WATIR and
those that worked through webrat.
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
Matt W.
http://blog.mattwynne.net
On Wed, Dec 24, 2008 at 11:17 AM, Matt W. [email protected] wrote:
features). Plus several other
bug fixes.
What’s this about support/* files? Is there some convention emerging around
structuring the features directory that I’ve missed?
This is where the Rails Cucumber generator puts the env.rb file. It
seems to
emerge as a layout for non-Rails projects too. Put the non- step
definition
ruby files that Cucumber needs here.
It would be cool to hear more from people about how they do this. I have a
feeling our structure at work could be better, but I’m not sure what other
models are out there.
I think your structure seems good. There is no one-size-fits-all here.
It
does seem common that people have some Ruby code that needs to be loaded
prior to the step definitions, and for the time being Cucumber will look
in
support first. It would be nice to provide a similar kind of feature for
projects tha are laid out differently. However, it should be possible to
achieve with cucumber.yml.
I’ve been putting step helper methods in the same file as the step
definitions. Do you think I should split them into separate support
files?