Removing web_steps.rb in Cucumber 1.1.0

[aslak hellesoy]

Hi all

The presence of web_steps.rb in Rails projects using Cucumber-Rails leads people down a very bad path. While it gives people a head start in writing scenarios it also tricks people into writing scenarios are extremely verbose and fragile. People who are new to Cucumber don't always realise this, so they continue cranking out lots of crap scenarios based on web_steps.rb. This is like the boiling frog story - you don't realise how messed up the situation is before it's too late and you have a TON of features nobody wants to touch.

web_steps.rb isn't much more than a thin layer around the Capybara API. As a result, many people don't even learn the Capybara API, which they should.

The Capybara API is well-documented. I want people to write their own step definitions in a more declarative style, specific to their domain. -With 3-4 Capybara calls in them.

If you disagree with this decision, please see this: http://skillsmatter.com/podcast/home/refuctoring-your-cukes

(Go see it even if you agree with me - it's awesome).

Cheers,

Aslak

[David Chelimsky]

Hooray!!!!!!!!!!!!!!!

[David Kowis]

+1

Yay!

David

[byrnejb]

On Sep 27, 10:17 am, aslak hellesoy <aslak.helle...@gmail.com> wrote:

>
> web_steps.rb isn't much more than a thin layer around the Capybara API. As a
> result, many people don't even learn the Capybara API, which they should.
> The Capybara API is well-documented. I want people to write their own step
> definitions in a more declarative style, specific to their domain. -With 3-4
> Capybara calls in them.
>

Removing web_steps.rb has my vote, for what it is worth. However, I
recall that the examples it contained, however misleading in the end,
were nonetheless helpful to me when first starting out with BDD and
Cucumber. Instead of simply removing it is it possible to simply
rename web_steps.rb to steps.examples and then perhaps refactor it so
as to show the more declarative style as desired? The result could be
installed into features/step_definitions where it would be available
as a guide for newbies and simply purged or ignored by old hands.

I will undertake to do said refactoring if this suggestion meets with
approval and if I can call upon the list to provide me with examples
to use in addition to my own. I would venture that most here have one
or two step definitions they have constructed which they feel are
particularly noteworthy for one reason or another. Those sort of
examples, together with a brief outline of what they do and why they
do it it in the manner chosen, would be particularly valuable for the
newcomer.

[Joaquin Rivera Padron]

2011/9/28 byrnejb <byr...@harte-lyne.ca>

+1
 

--
You received this message because you are subscribed to the Google Groups "Cukes" group.
To post to this group, send email to cu...@googlegroups.com.
To unsubscribe from this group, send email to cukes+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/cukes?hl=en.

--

para.pent.es vamos a volar, let's go flying
least-significant-bit.com

[aslak hellesoy]

On Wed, Sep 28, 2011 at 1:55 PM, byrnejb <byr...@harte-lyne.ca> wrote:

On Sep 27, 10:17 am, aslak hellesoy <aslak.helle...@gmail.com> wrote:

>
> web_steps.rb isn't much more than a thin layer around the Capybara API. As a
> result, many people don't even learn the Capybara API, which they should.
> The Capybara API is well-documented. I want people to write their own step
> definitions in a more declarative style, specific to their domain. -With 3-4
> Capybara calls in them.
>

Removing web_steps.rb has my vote, for what it is worth.  However, I
recall that the examples it contained, however misleading in the end,
were nonetheless helpful to me when first starting out with BDD and
Cucumber.

Then I would argue that it didn't really help you.

 

 Instead of simply removing it is it possible to simply
rename web_steps.rb to steps.examples and then perhaps refactor it so
as to show the more declarative style as desired?

There is no such thing as a generic declarative style. A declarative style is always domain-specific.

 The result could be
installed into features/step_definitions where it would be available
as a guide for newbies and simply purged or ignored by old hands.

A newbie presented with a short-cut will use it no matter how many warning labels it has. The absence of a short-cut will make it a little harder for them to get started, and for some it will be too hard.

The people who find it too hard to learn the Capybara API shouldn't be using Cucumber-Rails in the first place.

My goal isn't to amass the maximum number of users - my goal is to help people write better tests.

Sorry, Cucumber-Rails 1.1.0 will not have any web_steps.rb in any shape or form.

Aslak

 

I will undertake to do said refactoring if this suggestion meets with
approval and if I can call upon the list to provide me with examples
to use in addition to my own.  I would venture that most here have one
or two step definitions they have constructed which they feel are
particularly noteworthy for one reason or another.  Those sort of
examples, together with a brief outline of what they do and why they
do it it in the manner chosen, would be particularly valuable for the
newcomer.

[byrnejb]

On Sep 28, 9:10 am, aslak hellesoy <aslak.helle...@gmail.com> wrote:

> On Wed, Sep 28, 2011 at 1:55 PM, byrnejb <byrn...@harte-lyne.ca> wrote:
>
> > On Sep 27, 10:17 am, aslak hellesoy <aslak.helle...@gmail.com> wrote:
>
> > > web_steps.rb isn't much more than a thin layer around the Capybara API.
> > As a
> > > result, many people don't even learn the Capybara API, which they should.
> > > The Capybara API is well-documented. I want people to write their own
> > step
> > > definitions in a more declarative style, specific to their domain. -With
> > 3-4
> > > Capybara calls in them.
>
> > Removing web_steps.rb has my vote, for what it is worth.  However, I
> > recall that the examples it contained, however misleading in the end,
> > were nonetheless helpful to me when first starting out with BDD and
> > Cucumber.
>
> Then I would argue that it didn't really help you.

You can argue that, but it would not alter the fact that I did learn
much from examining the example steps.

[Joaquin Rivera Padron]

2011/9/28 byrnejb <byr...@harte-lyne.ca>

+1

2 cents: i normally work in those kind of teams where i have to really work hard to convince developers and management to give cucumber a try, they (even I) might do it wrong when they (I) do it, but still there's value in doing it 60% ok. I really think that rising the entry level is not an intelligent choice, imho

--

You received this message because you are subscribed to the Google Groups "Cukes" group.
To post to this group, send email to cu...@googlegroups.com.
To unsubscribe from this group, send email to cukes+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/cukes?hl=en.

[aslak hellesoy]

On Wed, Sep 28, 2011 at 3:20 PM, Joaquin Rivera Padron <joah...@gmail.com> wrote:

2011/9/28 byrnejb <byr...@harte-lyne.ca>

On Sep 28, 9:10 am, aslak hellesoy <aslak.helle...@gmail.com> wrote:

> On Wed, Sep 28, 2011 at 1:55 PM, byrnejb <byrn...@harte-lyne.ca> wrote:
>
> > On Sep 27, 10:17 am, aslak hellesoy <aslak.helle...@gmail.com> wrote:
>
> > > web_steps.rb isn't much more than a thin layer around the Capybara API.
> > As a
> > > result, many people don't even learn the Capybara API, which they should.
> > > The Capybara API is well-documented. I want people to write their own
> > step
> > > definitions in a more declarative style, specific to their domain. -With
> > 3-4
> > > Capybara calls in them.
>
> > Removing web_steps.rb has my vote, for what it is worth.  However, I
> > recall that the examples it contained, however misleading in the end,
> > were nonetheless helpful to me when first starting out with BDD and
> > Cucumber.
>
> Then I would argue that it didn't really help you.

You can argue that, but it would not alter the fact that I did learn
much from examining the example steps.

+1

2 cents: i normally work in those kind of teams where i have to really work hard to convince developers and management to give cucumber a try, they (even I) might do it wrong when they (I) do it, but still there's value in doing it 60% ok. I really think that rising the entry level is not an intelligent choice, imho

Why do you think that?

[Joaquin Rivera Padron]

2011/9/28 aslak hellesoy <aslak.h...@gmail.com>

On Wed, Sep 28, 2011 at 3:20 PM, Joaquin Rivera Padron <joah...@gmail.com> wrote:

2011/9/28 byrnejb <byr...@harte-lyne.ca>

On Sep 28, 9:10 am, aslak hellesoy <aslak.helle...@gmail.com> wrote:

> On Wed, Sep 28, 2011 at 1:55 PM, byrnejb <byrn...@harte-lyne.ca> wrote:
>
> > On Sep 27, 10:17 am, aslak hellesoy <aslak.helle...@gmail.com> wrote:
>
> > > web_steps.rb isn't much more than a thin layer around the Capybara API.
> > As a
> > > result, many people don't even learn the Capybara API, which they should.
> > > The Capybara API is well-documented. I want people to write their own
> > step
> > > definitions in a more declarative style, specific to their domain. -With
> > 3-4
> > > Capybara calls in them.
>
> > Removing web_steps.rb has my vote, for what it is worth.  However, I
> > recall that the examples it contained, however misleading in the end,
> > were nonetheless helpful to me when first starting out with BDD and
> > Cucumber.
>
> Then I would argue that it didn't really help you.

You can argue that, but it would not alter the fact that I did learn
much from examining the example steps.

+1

2 cents: i normally work in those kind of teams where i have to really work hard to convince developers and management to give cucumber a try, they (even I) might do it wrong when they (I) do it, but still there's value in doing it 60% ok. I really think that rising the entry level is not an intelligent choice, imho

Why do you think that?

when I started learning cucumber I needed time to have my brain grasp the whole thing. This is still the case when I see people trying it for the first time. Doing that start even more abstract will make it harder for them.

I am thinking specially in teams where that 3-amigos environment does not exist, teams where developers write the suite because they know it is the correct thing to do. There are teams were the "domain specific vocabulary" does not exist neither. There it is normally the case that e.g. "clicking a XYZ link" will make more sense that come up with a vocabulary that it is not correct

Also to developers abstracting the steps is not attractive, they love code. They need time to really learn that not writing code steps will help them. I might be mistaken, but cucumber is normally learned first by hackers and then they try to convince the management that it is the best way of doing things.

at least it is what I see around here... please take my words as a very opinionated ones, I do believe it is better to have the steps in the declarative way, only I find them more distant from the beginners
 

 

--

You received this message because you are subscribed to the Google Groups "Cukes" group.
To post to this group, send email to cu...@googlegroups.com.
To unsubscribe from this group, send email to cukes+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/cukes?hl=en.

--

para.pent.es vamos a volar, let's go flying
least-significant-bit.com

--

You received this message because you are subscribed to the Google Groups "Cukes" group.
To post to this group, send email to cu...@googlegroups.com.
To unsubscribe from this group, send email to cukes+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/cukes?hl=en.

--
You received this message because you are subscribed to the Google Groups "Cukes" group.
To post to this group, send email to cu...@googlegroups.com.
To unsubscribe from this group, send email to cukes+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/cukes?hl=en.

[Paul]

>>>> You can argue that, but it would not alter the fact that I did learn
>>>> much from examining the example steps.

I learned a lot from websteps, too. But, I already have a copy of it
that I can refer to, so it doesn't bother me if you stop including it.
That will only hurt people who are starting cucumber in the future.

[Gregory Hnatiuk]

I've them as a reference....but learned more in 5 minutes looking at the capybara documentation than in a year of looking at web_steps.
Maybe we can just paste in the DSL
 

[Gregory Hnatiuk]

On Wed, Sep 28, 2011 at 1:55 PM, Gregory Hnatiuk <ghna...@gmail.com> wrote:

On Wed, Sep 28, 2011 at 12:11 PM, Paul <pa...@nines.org> wrote:

>>>> You can argue that, but it would not alter the fact that I did learn
>>>> much from examining the example steps.

I learned a lot from websteps, too. But, I already have a copy of it
that I can refer to, so it doesn't bother me if you stop including it.
That will only hurt people who are starting cucumber in the future.

 
I've them as a reference....but learned more in 5 minutes looking at the capybara documentation than in a year of looking at web_steps.

Maybe we can just paste in the DSL ... section from github ;)
 

[byrnejb]

The question arises: Are the step definitions bundled with Aruba going
to be removed as well? If so then when? If not then why not?

[aslak hellesoy]

On Thu, Sep 29, 2011 at 2:33 PM, byrnejb <byr...@harte-lyne.ca> wrote:

The question arises: Are the step definitions bundled with Aruba going
to be removed as well?

I haven't given it much thought. Maybe they should. Maybe not.

 

 If so then when?  If not then why not?

Far less people are using them, so they cause less harm. CLI apps tend to be smaller than webapps, so I think the convenience of having stock steps outweighs the negative effects.

Besides, I think Aruba's stepdefs are actually more domain-specific than web_steps.rb because the end users are programmers. Their domain is "run this command, check this output". A webapp user's domain is not "click this link, look for this string".

Aslak

[Andrew Premdas]

> --
> You received this message because you are subscribed to the Google Groups
> "Cukes" group.
> To post to this group, send email to cu...@googlegroups.com.
> To unsubscribe from this group, send email to
> cukes+un...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/cukes?hl=en.
>

+1 ( or as many as I'm allowed)

The best thing in web steps was the statement in web steps telling
people not to write steps like the ones in web steps.

I think you could write a good set of domain specific steps to give
people a guide. Choosing something like Sign In/Sign Out, which is
fairly common in web apps. Perhaps we could create a github project
for this and link to it in Cucumber's readme, so we can give people a
lift with starting out.

All best

Andrew
--
------------------------
Andrew Premdas
blog.andrew.premdas.org

[Andy Waite]

On Sunday, 2 October 2011 at 19:58, Andrew Premdas wrote:

I think you could write a good set of domain specific steps to give
people a guide. Choosing something like Sign In/Sign Out, which is
fairly common in web apps. Perhaps we could create a github project
for this and link to it in Cucumber's readme, so we can give people a
lift with starting out.

This sounds like a great idea - a fleshed-out, well-commented sample app which new users could clone from Github, watch the features pass (perhaps demonstrating a mix of Mechanize and Selenium), and then study 'behind the scenes' to learn how it works.

Andy

[Julien Biezemans]

On Sun, Oct 2, 2011 at 8:58 PM, Andrew Premdas <apre...@gmail.com> wrote:
>
> I think you could write a good set of domain specific steps to give
> people a guide. Choosing something like Sign In/Sign Out, which is
> fairly common in web apps. Perhaps we could create a github project
> for this and link to it in Cucumber's readme, so we can give people a
> lift with starting out.

This would be nice. Matt suggested something similar
(https://github.com/cucumber/cucumber-rails/commit/f027440965b96b780e84e50dd47203a2838e8d7d#commitcomment-624933)
on the related Github issue and I did too, somewhere (can't find it
back).

Here is a copy of my latest thoughts, expressed as a reply to Matt's
comment on Github (I should have done that here in the first place
:)):

> I think we need to put some effort into writing some decent online tutorials to show this group how to do it the right way. It isn't hard when you know how.

+1 to that. I'd be glad to help.

Also, it would be nice to clarify what is Behaviour-Driven
Development. It looks to me that for some, BDD has become a cooler
name for TDD, a synonym for acceptance tests, integration tests, tests
for people who can't write code. In my mind it's much more than
programming techniques.

I think The Cucumber Book is going to help a lot for understanding the
purpose of Cucumber and what is BDD in general. It seems like a great
step forward to me.

But of course, not everyone is going to buy it (unfortunately ;)).

In that respect, the death of web steps is also a good thing.

To use Cucumber "right" (i.e. as a BDD tool), one has to understand
that communication is essential and Cucumber's main goal is primarily
about communication and secondarily about testing.

The cukes.info homepage mentions the word "test" at least 8 times
while "behaviour" appears only once. Maybe it's time to think again
about the words used to promote and document Cucumber. We're supposed
to embrace the ubiquitous language concept: let's do that in our own
documentation!

E.g. don't use the word "test", use "scenario": unconsciously it will
probably have the effect of thinking more about Cucumber as an
efficient way for expressing behaviour rather than a "testing tool".

My point is: Cucumber is pretty well known today and it should use
that renown to foster higher BDD values and concepts. Actually, I
think that message is already carried by Cucumber, but in a clumsy
fashion. Of course, there are certainly fair and understandable
reasons to that. But now that Cucumber has matured and knows its way,
maybe it's time to focus on and improve its message.

[Brent]

> A webapp user's domain is not "click this
link, look for this string".

I thought this was about the behavior of the user,
not the programmer coding it?

I understand that trying to clean up features is a good idea.
Sure it makes sense to refactor steps into more concise readable
and expressive sentence, I think the fundamental issue is that people
don't refactor, they don't tend to see patterns of commonality and
clean stuff up, or they just don't bother.

I just installed a new rails app, and my first feature was to allow
a user to signup.

this feature was not: "And I signup"
I have not figured out how that happens yet.
If I am thinking about the user experience I am thinking
of first loading the homepage and then clicking the "signup" link.
and waiting to see the next page.

I will extract these steps later when I want to re-use this.
What's wrong with this exactly?

I have watched the video referenced (MDD).

I think that there are some good ideas here and the features
are even more clear than I tend to make them.
I think the goals are good, but the approach is annoying.

> I want people to write their own step definitions in a more declarative style, specific to their domain. -With 3-4 Capybara calls in them.

Sure, fine, have you actually achived that though?
You just hid the cookie jar, and not very well.



...


On Sep 29, 3:04 pm, aslak hellesoy <aslak.helle...@gmail.com> wrote:

[aslak hellesoy]

On Fri, Oct 7, 2011 at 9:58 PM, Brent <brent...@gmail.com> wrote:

> A webapp user's domain is not "click this
link, look for this string".

I thought this was about the behavior of the user,
not the programmer coding it?

The B in BDD is about the behaviour of the system and the user using it. Is this what you meant to clarify?

 

I understand that trying to clean up features is a good idea.
Sure it makes sense to refactor steps into more concise readable
and expressive sentence, I think the fundamental issue is that people
don't refactor, they don't tend to see patterns of commonality and
clean stuff up, or they just don't bother.

I just installed a new rails app, and my first feature was to allow
a user to signup.

How did you decide to do this first?

 

this feature was not: "And I signup"
I have not figured out how that happens yet.
If I am thinking about the user experience I am thinking
of first loading the homepage and then clicking the "signup" link.
and waiting to see the next page.

I will extract these steps later when I want to re-use this.
What's wrong with this exactly?

I have watched the video referenced (MDD).

I think that there are some good ideas here and the features
are even more clear than I tend to make them.
I think the goals are good, but the approach is annoying.

What approach?

 

> I want people to write their own step definitions in a more declarative style, specific to their domain. -With 3-4 Capybara calls in them.

Sure, fine, have you actually achived that though?

I think so: http://aslakhellesoy.com/post/11055981222/the-training-wheels-came-off

 

You just hid the cookie jar, and not very well.

I love metaphors, but you lost me here.

Aslak

[byrnejb]

On Oct 8, 4:09 am, aslak hellesoy <aslak.helle...@gmail.com> wrote:

> On Fri, Oct 7, 2011 at 9:58 PM, Brent <brentgre...@gmail.com> wrote:

> > You just hid the cookie jar, and not very well.
>
> I love metaphors, but you lost me here.
>
> Aslak

I think that the basic issue is that a crutch (websteps == cookie
jar) for the newcomer has been removed (hidden).

I feel uneasy about the entire way this decision has been presented as
a transition from childhood to maturity. The issue is simply one of
ignorance and knowledge. Making it more difficult for someone to
move from ignorance to knowledge does not strike me as a good thing.
I agree that the existing web steps were of questionable value once a
certain level of experience was reached. No doubt the same lesson of
why the declarative style is superior to the imperative style was
painfully learned and relearned by many, perhaps most, first time
users of Cucumber.

However, I wonder if trying to prevent this experience is not
actually counterproductive. When learning to walk you have to fall
down, repeatedly. When learning to write you have to produce a lot of
wastepaper. It is just the way things are. I think that a lot of
intellectual progress is obtained in similar fashion, you have to
first experience the failure to recognize and master the success.

Consider the intellectual barriers to entry that removing such
crutches create. It is hard enough on its own to learn anything new.
There often exists the need to master new forms of expression, perhaps
mapping new meanings to familiar terms. Frequently one must deal with
a host of apparently related nigglies, where one lacks the experience
and knowledge to discern what is important from what is not. In
consequence the biggest difficulty often becomes simply how to start.
However poor an example they were, websteps at least had the virtue of
existing and providing an example of how to get started. The
countless "hello world" programs in existence are hardly of any
greater worth and yet they are ubiquitous. There is a reason for
that.

The difficulty that masters have with neophytes is that much of what
is now unconscious to the master often represents a formidable barrier
to the neophyte, and once did to the master as well. However, the
master no longs sees the utility in maintaining something that no
longer provides them with any value, even though once it was valuable
enough for them to create. So they dispense with it. And those who
are not masters thereafter have no opportunity to experience that
which the master once valued, but no longer does.

One may liken the situation to crossing a chasm on a rope bridge in
order to learn how to fly and then removing the rope bridge in the
belief that everyone really should just fly. True insofar as it goes,
but what if it was the very passage over the rope bridge which started
the process of mastering flight? What then of those that follow? Ah,
they must find their own path to flight, a path that might only be
visible to those that already can fly.

[aslak hellesoy]

On Tue, Oct 11, 2011 at 4:16 PM, byrnejb <byr...@harte-lyne.ca> wrote:

On Oct 8, 4:09 am, aslak hellesoy <aslak.helle...@gmail.com> wrote:

> On Fri, Oct 7, 2011 at 9:58 PM, Brent <brentgre...@gmail.com> wrote:

> > You just hid the cookie jar, and not very well.
>
> I love metaphors, but you lost me here.
>
> Aslak

I think that the basic issue is that a crutch (websteps == cookie
jar)  for the newcomer has been removed (hidden).

I feel uneasy about the entire way this decision has been presented as
a transition from childhood to maturity.  The issue is simply one of
ignorance and knowledge.   Making it more difficult for someone to
move from ignorance to knowledge does not strike me as a good thing.
I agree that the existing web steps were of questionable value once a
certain level of experience was reached.  No doubt the same lesson of
why the declarative style is superior to the imperative style was
painfully learned and relearned by many, perhaps most, first time
users of Cucumber.

However, I wonder if trying to prevent this experience is not
actually counterproductive.  When learning to walk you have to fall
down, repeatedly.  When learning to write you have to produce a lot of
wastepaper.  It is just the way things are.  I think that a lot of
intellectual progress is obtained in similar fashion, you have to
first experience the failure to recognize and master the success.

You mean like the only way to learn to drive a car is to hop in and get on the highway?

That's actually the way it's done in some (most?) parts of the world.

Thanks for this nice summary James. I didn't quite understand whether or not you were asking me to put web_steps back?

[Paul]

Personally, I'm at a point where I really, really want to incorporate
Cucumber and I'm finding it fairly easy to create imperative scenarios
and I tend to get stuck and work slower trying to get to declarative
ones. I'm ready for the "Declarative Cucumber for Dummies" book. But
until then, at least I'm getting something out of Cucumber.

I did find it useful to "touch the hot stove" of web_steps. It's given
me the understanding of what the pitfalls are and I think it was a
useful exercise.

I just think that there are those of us who feel like there are a
"couple missing rungs in the ladder".

[Matt Wynne]

On 11 Oct 2011, at 19:16, Paul wrote:

Personally, I'm at a point where I really, really want to incorporate
Cucumber and I'm finding it fairly easy to create imperative scenarios
and I tend to get stuck and work slower trying to get to declarative
ones. I'm ready for the "Declarative Cucumber for Dummies" book. But
until then, at least I'm getting something out of Cucumber.

I did find it useful to "touch the hot stove" of web_steps. It's given
me the understanding of what the pitfalls are and I think it was a
useful exercise.

I just think that there are those of us who feel like there are a
"couple missing rungs in the ladder".

This might be just my "oh I can already fly" perspective, but I think it's much simpler than you imagine.

Just open up the feature file and write down, exactly as you would explain it to your mum, what you want the system to do. Forget about buttons and forms and stuff, just describe the *behaviour* you want.

Here's an example I wrote very recently:

https://www.relishapp.com/relish/relish/docs/guest-access/guest-access-via-url

Does that help?

cheers,

Matt

--
Freelance programmer & coach

Author, http://pragprog.com/book/hwcuc/the-cucumber-book (with Aslak Hellesøy)
Founder, http://relishapp.com
+44(0)7974430184 | http://twitter.com/mattwynne

[Matt Wynne]

On 11 Oct 2011, at 16:16, byrnejb wrote:

> One may liken the situation to crossing a chasm on a rope bridge in
> order to learn how to fly and then removing the rope bridge in the
> belief that everyone really should just fly. True insofar as it goes,
> but what if it was the very passage over the rope bridge which started
> the process of mastering flight? What then of those that follow? Ah,
> they must find their own path to flight, a path that might only be
> visible to those that already can fly.

Sorry James, but I have to call "bollocks" to that. web_steps was a dead end.

[Steve Tooke]

On 27 September 2011 15:17, aslak hellesoy <aslak.h...@gmail.com> wrote:

Can I just clarify that web_steps.rb is only being removed from the gem, so it won't be added to new projects when they generate cucumber?

Any projects which have a web_steps.rb already won't be losing it when they update, I'm guessing?

Steve

 

--

Steve Tooke :: heavi.es

+44 7919 337 463 :: +44 20 8133 4134

skype:stevetooke :: twitter.com/tooky

Heavies Limited

Registered Number: 7612561

Registered Address: Parmenter House, 57 Tower Street, Winchester SO23 8TD

[aslak hellesoy]

On Wed, Oct 12, 2011 at 4:23 PM, Steve Tooke <st...@heavi.es> wrote:

On 27 September 2011 15:17, aslak hellesoy <aslak.h...@gmail.com> wrote:

Hi all

The presence of web_steps.rb in Rails projects using Cucumber-Rails leads people down a very bad path. While it gives people a head start in writing scenarios it also tricks people into writing scenarios are extremely verbose and fragile. People who are new to Cucumber don't always realise this, so they continue cranking out lots of crap scenarios based on web_steps.rb. This is like the boiling frog story - you don't realise how messed up the situation is before it's too late and you have a TON of features nobody wants to touch.

web_steps.rb isn't much more than a thin layer around the Capybara API. As a result, many people don't even learn the Capybara API, which they should.

The Capybara API is well-documented. I want people to write their own step definitions in a more declarative style, specific to their domain. -With 3-4 Capybara calls in them.

If you disagree with this decision, please see this: http://skillsmatter.com/podcast/home/refuctoring-your-cukes

(Go see it even if you agree with me - it's awesome).

Can I just clarify that web_steps.rb is only being removed from the gem, so it won't be added to new projects when they generate cucumber?

Any projects which have a web_steps.rb already won't be losing it when they update, I'm guessing?

That's right

 

Steve

 

--

Steve Tooke :: heavi.es

+44 7919 337 463 :: +44 20 8133 4134

skype:stevetooke :: twitter.com/tooky

Heavies Limited

Registered Number: 7612561

Registered Address: Parmenter House, 57 Tower Street, Winchester SO23 8TD

[Lenny Marks]

On Oct 7, 2011, at 4:58 PM, Brent wrote:

A webapp user's domain is not "click this

link, look for this string".

I thought this was about the behavior of the user,
not the programmer coding it?

I understand that trying to clean up features is a good idea.
Sure it makes sense to refactor steps into more concise readable
and expressive sentence, I think the fundamental issue is that people
don't refactor, they don't tend to see patterns of commonality and
clean stuff up, or they just don't bother.

I just installed a new rails app, and my first feature was to allow
a user to signup.

this feature was not: "And I signup"
I have not figured out how that happens yet.
If I am thinking about the user experience I am thinking
of first loading the homepage and then clicking the "signup" link.
and waiting to see the next page.

I will extract these steps later when I want to re-use this.
What's wrong with this exactly?

I don't care to weigh in on the web_steps.rb debate but as far as the above.. Although there is a lot of overlap, I think there is a lot of confusion around the different goals and audiences you may be targeting Cukes for. Specification, testing, outside in development, live documentation, etc.. I'm splicing in Matt's related comments from a snipped message elsewhere in this thread.

On Oct 11, 2011, at 3:53 PM, Matt Wynne wrote:

This might be just my "oh I can already fly" perspective, but I think it's much simpler than you imagine.

Just open up the feature file and write down, exactly as you would explain it to your mum, what you want the system to do. Forget about buttons and forms and stuff, just describe the *behaviour* you want.

Here's an example I wrote very recently:

https://www.relishapp.com/relish/relish/docs/guest-access/guest-access-via-url

I understand the perils/brittleness of imperative steps, but just wanted to confirm there is still some agreement between those that can fly that they can still smell fine sometimes.  I find an imperative scenario or two to be a good thing, especially in the context of live documentation or working out how a user should/will interact with the system. If I was explaining to my mum how to use any given feature of my application that required her to be authenticated, I would certainly have had to explain somewhere, at least once how to do that (i.e. the imperative scenario like Brent used above... go to the home page and click the signup link). Of course, once that's out of the way, I want declarative steps like "Given I have logged in". It can be hard to find the right balance between the two styles. Even using the simple Calculator/Addition feature from the http://cukes.info page. 

Feature: Addition

  In order to ....

 

Given I add two numbers

Then I should see the correct result

vs. 

Given I press 5

And I press +

And I press 5

And I press =

Then the result should be 10 

vs. the cukes.info version or a scenario outline version that throws a bunch of numbers at it.

Which one is best?? I dunno, is the goal to document that my that my calculator can/should add and why, describe how to add numbers, prove that it adds correctly, etc?? Personally I think Cukes often go wrong(too imperative) when they are geared too much toward testing and there are better tools for that(i.e rspec). And I'm not sold on using Cucumber as a specification/project tracking tool (although I find thinking Features/Gherkin helpful there). I find it most appealing as live documentation tool. RSpec is great to get at all the innards of a system but having the plain text documentation of what it does, why, and how it interacts from the outside is it.  

My 2 cents.

-lenny

[Jonathan Linowes]

My take is this is a natural progression from the community realizing we can use capybara directly in rspec for integration testing. At first that got people realizing, "hey, i don't need those extra natural language steps layer in cucumber, i'll just do my integration tests in rspec". Which led cukers to (further) re-examine the core value of cucumber-- more for BDD and communication of requirements and acceptance criteria of features, and less as an integration testing framework. All for the better, imo. What we could use now are more good tutorials on the capybara api.

--linoj

[Eric Pierce]

I've been following this discussion with some interest. I'm in the
slightly uncomfortable position of agreeing with the removal of
web_steps.rb, while simultaneously being the author of a tool
(Kelp[1]) that generates its own web_steps.rb, strongly based on the
ones that were formerly provided by cucumber-rails.

Having said that I agree with their removal from cucumber-rails, I
have some amount of concern that this will be perceived as making
things harder for users. Yes, it's for their own good (in the long
run), and yes, many experienced Cukers agree that web_steps.rb is bad
news, but removing them means more up-front work for new users to do.
No longer is it possible to install cucumber and cucumber-rails, jot
down a .feature file, and have it work right away. You have to define
your own step definitions from scratch. Maybe this too is for the
best; great power -> great responsibility, and a steeper learning
curve can lead to much better understanding. But I'd be a little more
hesitant to introduce Cucumber to newbies now. Before cucumber-rails
1.1.0, the generator got you 90% of the way to running your first
scenario. Now, there's some assembly required.

Anyhow, I saw Aslak's comments on the Github ticket #174 that perhaps
someone would step up and fill the void left by the removal of
web_steps.rb. I think Kelp does that rather neatly, while (I hope)
also encouraging better step definition practices through its higher-
level wrappers for the imperative stuff. I've added a couple
paragraphs to the top of its README to that effect. If anyone here
misses web_steps.rb, you may find what you're looking for there.

[1] https://github.com/wapcaplet/kelp

[George Dinwiddie]

Paul,

On 10/11/11 2:16 PM, Paul wrote:
> Personally, I'm at a point where I really, really want to incorporate
> Cucumber and I'm finding it fairly easy to create imperative scenarios
> and I tend to get stuck and work slower trying to get to declarative
> ones. I'm ready for the "Declarative Cucumber for Dummies" book. But
> until then, at least I'm getting something out of Cucumber.

Have you read the current (not quite on paper, but available in beta)
Cucumber Book? I found the advice on declarative style tests in that to
be quite good.

- George

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[Matt Wynne]

On 8 Nov 2011, at 23:50, George Dinwiddie wrote:

> On 10/11/11 2:16 PM, Paul wrote:
>> I tend to get stuck and work slower trying to get to declarative
>> ones.

Working slower is to be expected when you're using a declarative style---at first, anyway---but this is a good thing! Let me explain why.

When you use an imperative style, you don't need to think in terms of your domain language. You just think (and write) in terms of a generic domain language about clicking UI widgets. Trying to use a declarative style will not let you get away with that, and you'll have to actually come up with names for the things that you're doing that are meaningful in your domain. This isn't easy, but it's very valuable. Once you've established a common (or ubiquitous) language on your team for talking about your domain, you'll find conversations about your day-to-day activities on the project flow a lot more smoothly.

There is no book that can tell you what those words are---it's something you and your team will have to discover for themselves. That's why it's important to try to have a domain expert nearby or ideally pairing with you as you write these scenarios, so that you can thrash out your domain language as the questions come up. The more of your domain language you discover, the easier this gets, and pretty soon you'll find the declarative style actually allows you to move more quickly than the laborious imperative style.