Forum: RSpec [ANN] Cucumber 0.1.13

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Aslak H. (Guest)
on 2008-12-20 23:27
(Received via mailing list)
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-cucu...

Full release notes on GitHub:
http://github.com/aslakhellesoy/cucumber/tree/v0.1...

Cheers,
Aslak
Matt W. (Guest)
on 2008-12-24 12:30
(Received via mailing list)
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
> removed_email_address@domain.invalid
> http://rubyforge.org/mailman/listinfo/rspec-users

Matt W.
http://blog.mattwynne.net
http://www.songkick.com
Aslak H. (Guest)
on 2008-12-24 13:13
(Received via mailing list)
On Wed, Dec 24, 2008 at 11:17 AM, Matt W. <removed_email_address@domain.invalid> 
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.
Jonathan L. (Guest)
on 2008-12-24 15:14
(Received via mailing list)
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?
This topic is locked and can not be replied to.