Where to start after writing feature

I am trying to develop code from the feature on down.

So I created a brand new rails app. It has no models yet. I wrote a
feature:

Feature: Add tasks
In order to track website improvements
a user
wants to add tasks

Scenario: User adds task
Given task “Display Group Rules” does not exist
When I visit “/tasks/new”
And I fill in “Name” with “Display Group Rules”
And I fill in “Description” with “Displays links to edit each group
rule”
And I fill in “CAS Link” with “GroupRulesManager/”
And I press “Submit”
Then I should end up on the Tasks page
And I should see “Task successfully added”
And the task “Display Group Rules” should exist

I then run:

rake db:migrate (this creates my development SQLite3 database)
rake db:test:prepare (this creates my development SQLite3 database)
rake features (outputs the following:)

Feature: Add tasks # features/manage_task.feature
In order to track website improvements
a user
wants to add tasks
Scenario: User adds task
Given task “Display Group Rules” does not exist
When I visit “/tasks/new”
And I fill in “Name” with “Display Group Rules”
And I fill in “Description” with “Displays links to edit each group
rule”
And I fill in “CAS Link” with “GroupRulesManager/”
And I press “Submit”
Then I should end up on the Tasks page
And I should see “Task successfully added”
And the task “Display Group Rules” should exist

5 steps skipped
4 steps pending

You can use these snippets to implement pending steps:

Given /^task “Display Group Rules” does not exist$/ do
end

When /^I visit “/tasks/new”$/ do
end

Then /^I should end up on the Tasks page$/ do
end

Then /^the task “Display Group Rules” should exist$/ do
end

My question is where to go from here. Do I implement the four pending
steps,
e.g:

Given /^task “(.+)” does not exist$/ do |name|
task = Task.find_by_name(name)
task.destroy if task
end

Or do I run:

./script/generate scaffold_resource task name:string description:text
cas_link:string

and the rake rspec and fix whatever errors show up there?

What are your thoughts? TIA

I think is better create the step ( it will no work ) and then run
script/generate rspec_scaffold Task name:string description:text
cas_link:string

or if you not using rspec:
script/generate scaffold Task name:string description:text
cas_link:string

Atenciosamente,

Daniel L.  Area Criações
Design, Websites e Sistemas Web

Visite: http://www.areacriacoes.com.br/projects
http://blog.areacriacoes.com.br/


55 (31) 3077-4560 / 55 (31) 8808-8748 / 55 (31) 8737-7501

On Fri, Dec 5, 2008 at 3:36 PM, Stephen V. [email protected] wrote:

Given task "Display Group Rules" does not exist

I then run:
Given task “Display Group Rules” does not exist

Given /^task “(.+)” does not exist$/ do |name|

What are your thoughts? TIA

Hi Stephen,

The approach I like to take is to follow the guidance of the system
(cucumber + rspec) every step of the way. Right now there are no
passing steps, so I’d write the code for the 1st pending step, run the
features and find the first thing that is missing or failing.

In the example you’ve provided, I’d very likely write code like what
you wrote for the first Given step. I imagine that running that
feature would produce an error saying that there is nothing named
Task.

At that point I’ve gone in two different directions. The more purist
approach would be to create the model at this point - not the scaffold

  • as that’s the only thing you actually need at this moment to
    progress.

I’ve also made the scaffold at this point. Typically I end up cutting
out a bunch of crap I don’t need and from time to time I don’t clear
out all the crap I don’t need, discovering later that I’ve got excess
code floating around the system. This is the motivation for avoiding
code generation. It’s a tradeoff.

Either way, once that step is passing (by creating the model or
scaffold and then running the migrations), I’d move on to the next
step. Just work your way down, one step at a time.

As your doing this, if you’re using the rspec generators, you’ll be
generating specs as you go. Any time that you need to actually
implement something in the code that is not generated, I’d head to the
specs to drive that additional behaviour out at the object level.

If you follow this with serious discipline, you’ll end up with two
concentric cycles that both follow a Red/Green/Refactor cycle, meeting
at the Green points.

One nice visual analogy for this is a two speed bicycle. The lower
gear, the bigger circle, is the Cucumber cycle. You work there until
you have a failing step, at which point you shift into high gear,
which is the smaller circle, the RSpec cycle. At the point that all
specs are passing and the last failing step is now passing, you shift
back to low gear (Cucumber) and work there until you have a failing
step. Rinse, repeat.

This is how I describe this in The RSpec Book, btw, so tell me now if
it doesn’t make sense :slight_smile:

HTH,
David

+1 to Davids advice

But first I would analyse the feature I’ve written. Some of the things
I’d
think about include

  1. The use of the word task - its not very precise

  2. The assumptions made in my story and whether I’m ready to make these
    yet

    a) That a task will have a name
    b) That only English users will be using this page
    c) That people will now what a CAS link is

  3. The brittleness of what I’ve written - what will change and how will
    I
    have to modify what I’ve done

So my initial scenario might be

When I create a new improvement
I should see a confirmation

and my second scenario might be

Given there are some improvements
I should be able to view improvements

Finally have a think about whether this feature is actually important
enough
to be doing first.

HTH

2008/12/5 Stephen V. [email protected]

Andrew P. wrote:

So my initial scenario might be

When I create a new improvement
I should see a confirmation

and my second scenario might be

Given there are some improvements
I should be able to view improvements

Finally have a think about whether this feature is actually important
enough
to be doing first.

The question arises, how does one tell what is important enough to begin
with? I am trying to form a robust mental pattern for employing BDD and
I keep running up against the tension between what I already believe to
be necessary to provide from my prior knowledge and what point to begin
with in features to cause this to be expressed. The examples that I
have found regarding how to use BDD features run the gamut from
specifying model attributes and data normalization to macro statements
of the form:

Given I have a web application
When I visit the application url
Then I should see a welcome message
And I should see a sign in request

etc.

So, the question I have is:

Given I have an application design document
When I specify the design using BDD
Then I should first begin with ???

On Fri, Dec 5, 2008 at 8:08 PM, David C. [email protected]
wrote:

Scenario: User adds task

Scenario: User adds task

end

and the rake rspec and fix whatever errors show up there?
In the example you’ve provided, I’d very likely write code like what
out a bunch of crap I don’t need and from time to time I don’t clear
implement something in the code that is not generated, I’d head to the
specs to drive that additional behaviour out at the object level.

If you follow this with serious discipline, you’ll end up with two
concentric cycles that both follow a Red/Green/Refactor cycle, meeting
at the Green points.

Actually, they’re not concentric - one is smaller and completely
inside the other, but they meet at one point in the circumference (so
they don’t share a center).

“There are two ways of constructing a software design: One way is to
make it
so simple that there are no obvious deficiencies, and the other way is
to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult”

C. A. R. Hoare, Professor of Computing, Oxford University (and inventor
of
the quicksort algorithm

No one said its easy :slight_smile:

2008/12/7 James B. [email protected]

Your very welcome :slight_smile:

2008/12/7 Dan N. [email protected]

Hooray! I’ve been looking for a reference for that quote for years!
Thanks
Andrew.

2008/12/7 Andrew P. [email protected]

In the future, if you’re going to +1 his advice could you please include
it in your email? I have to go searching for it now.

Pat

“Andrew P.” [email protected] writes:

Ok sorry bout that, perils of using gmail I guess…

2008/12/8 Pat M. [email protected]

Pat M. wrote:

In the future, if you’re going to +1 his advice could you please include
it in your email? I have to go searching for it now.

Pat

“Andrew P.” [email protected] writes:

Where to start after writing feature - RSpec - Ruby-Forum. Third from the top.

Regards,