From noreply at rubyforge.org  Thu Nov  1 07:12:16 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu,  1 Nov 2007 07:12:16 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-15255 ] Views generated incorrectly from
	script/generate rspec_controller when using modules
Message-ID: <20071101111217.06616185861C@rubyforge.org>

Bugs item #15255, was opened at 2007-11-01 12:12
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=15255&group_id=797

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: h a (haarts)
Assigned to: Nobody (None)
Summary: Views generated incorrectly from script/generate rspec_controller when using modules

Initial Comment:
OS: Mac OSX 10.4.10
Rails: Edge (rev 7910)
Rspec: rev 2719
Rspec_on_rails: rev 2719

When using:
./script/generate rspec_controller foo::bar example1 example2
the generated example(1|2).html.erb_spec.rb contains a broken regular expression. Line 10 reads:
response.should have_tag('p', /Find me in app\/views\/foo/bar\/example1/)
while it should read:
response.should have_tag('p', /Find me in app\/views\/foo\/bar\/example1/)
                                                        ^^^^
Note the escape character between foo and bar.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=15255&group_id=797

From undees at gmail.com  Thu Nov  1 10:59:37 2007
From: undees at gmail.com (Ian Dees)
Date: Thu, 1 Nov 2007 07:59:37 -0700
Subject: [rspec-devel] Dev Process (was Am I missing something with Heckle?)
Message-ID: <ad4f9af90711010759n48565114t651e8f9684479a33@mail.gmail.com>

Quoth Dave:

> We've been thinking of mercurial actually.

Three enthusiastic thumbs up for Mercurial!  About six months ago, I
stopped using the company-mandated Big Nasty Corporate SCM Tool
(rhymes with EarFace) in favor of Mercurial, with a few Ruby scripts
to sync back and forth.

In addition to having fast and painless merges, Mercurial has actually
saved me from my own stupidity several times.

--Ian

From noreply at rubyforge.org  Thu Nov  1 11:26:37 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu,  1 Nov 2007 11:26:37 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-15261 ] Green descriptions
	are also clickable
Message-ID: <20071101152637.7532418585E1@rubyforge.org>

Feature Requests item #15261, was opened at 2007-11-01 10:26
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=15261&group_id=797

Category: RSpec.tmbundle
Group: None
Status: Open
Priority: 3
Submitted By: Dean Wampler (deanwampler)
Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: Green descriptions are also clickable

Initial Comment:
When a spec fails, it's great that you can click the stack trace links to go to the code. I would like ability to click the green descriptions and "shoulds" to go to the spec code. 

I often run specs to get the overview of behavior, then I want to drill down to the details in the spec code itself.  

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=15261&group_id=797

From noreply at rubyforge.org  Fri Nov  2 04:07:22 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri,  2 Nov 2007 04:07:22 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-15282 ] POST,
	PUT and DELETE incorrectly append params to the request_uri
Message-ID: <20071102080722.5447018585BC@rubyforge.org>

Bugs item #15282, was opened at 2007-11-02 03:07
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=15282&group_id=797

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jeff Dean (jefdean)
Assigned to: Nobody (None)
Summary: POST, PUT and DELETE incorrectly append params to the request_uri

Initial Comment:
Given this form:

<pre><code>
<form action="/sessions/baz" method="post">
  <input type="text" name="foo" value="bar" />
  <input type="submit" />
</form>
</code></pre>

And this action:

<pre><code>
 class SessionsController < ApplicationController
  def baz
    render :text => "#{request.request_uri}<br/>#{params.inspect}"
  end
 end
</code></pre>

Submitting the form yields this output:

<pre><code>
/sessions/baz
{"action"=>"baz", "foo"=>"bar", "controller"=>"sessions"}
</code></pre>

This spec:

<pre><code>
describe SessionsController do
 it "should not append params to POST" do
  post :baz, :foo => :bar
  request.request_uri.should == "/sessions/baz"
 end
end
</code></pre>

Fail with this message:

<pre><code>
expected: "/sessions/baz",
     got: "/sessions/baz?foo=bar" (using ==)
</code></pre>

Notice how in the real app, rails properly interprets the request.request_uri, but in rspec_on_rails, the POST parameters are appended to the request_uri like GET paramaters. 

This is a bug because the spec does not correctly represent the behavior of rails.  I came up against this as I was trying to write a redirect that was based on the url of a page that was posted to, i.e.:

User posts form
Site recognizes that user is not logged in
Site redirects to login page, but stores params and request_uri
After login, repost the params to the request_uri

And I couldn't find a way to spec that.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=15282&group_id=797

From noreply at rubyforge.org  Fri Nov  2 07:25:05 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri,  2 Nov 2007 07:25:05 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-15282 ] POST,
	PUT and DELETE incorrectly append params to the request_uri
Message-ID: <20071102112505.C842118585DC@rubyforge.org>

Bugs item #15282, was opened at 2007-11-02 08:07
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=15282&group_id=797

Category: rails plugin
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 3
Submitted By: Jeff Dean (jefdean)
>Assigned to: David Chelimsky (dchelimsky)
Summary: POST, PUT and DELETE incorrectly append params to the request_uri

Initial Comment:
Given this form:

<pre><code>
<form action="/sessions/baz" method="post">
  <input type="text" name="foo" value="bar" />
  <input type="submit" />
</form>
</code></pre>

And this action:

<pre><code>
 class SessionsController < ApplicationController
  def baz
    render :text => "#{request.request_uri}<br/>#{params.inspect}"
  end
 end
</code></pre>

Submitting the form yields this output:

<pre><code>
/sessions/baz
{"action"=>"baz", "foo"=>"bar", "controller"=>"sessions"}
</code></pre>

This spec:

<pre><code>
describe SessionsController do
 it "should not append params to POST" do
  post :baz, :foo => :bar
  request.request_uri.should == "/sessions/baz"
 end
end
</code></pre>

Fail with this message:

<pre><code>
expected: "/sessions/baz",
     got: "/sessions/baz?foo=bar" (using ==)
</code></pre>

Notice how in the real app, rails properly interprets the request.request_uri, but in rspec_on_rails, the POST parameters are appended to the request_uri like GET paramaters. 

This is a bug because the spec does not correctly represent the behavior of rails.  I came up against this as I was trying to write a redirect that was based on the url of a page that was posted to, i.e.:

User posts form
Site recognizes that user is not logged in
Site redirects to login page, but stores params and request_uri
After login, repost the params to the request_uri

And I couldn't find a way to spec that.

----------------------------------------------------------------------

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-02 11:25

Message:
RSpec controller specs wrap Rails functional tests, which handle this request.

Here's a similar test in Rails:

  def test_should_not_append_params_to_post
    post :baz, :foo => :bar
    assert_equal "/sessions/baz", @request.request_uri
  end

And here's the output:

  <"/sessions/baz"> expected but was
  <"/sessions/baz?foo=bar">.

I'd recommend posting this but to the Rails tracker.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=15282&group_id=797

From noreply at rubyforge.org  Fri Nov  2 07:26:32 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri,  2 Nov 2007 07:26:32 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-15282 ] POST,
	PUT and DELETE incorrectly append params to the request_uri
Message-ID: <20071102112632.DB9F118585E5@rubyforge.org>

Bugs item #15282, was opened at 2007-11-02 08:07
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=15282&group_id=797

Category: rails plugin
Group: None
Status: Closed
Resolution: Rejected
Priority: 3
Submitted By: Jeff Dean (jefdean)
Assigned to: David Chelimsky (dchelimsky)
Summary: POST, PUT and DELETE incorrectly append params to the request_uri

Initial Comment:
Given this form:

<pre><code>
<form action="/sessions/baz" method="post">
  <input type="text" name="foo" value="bar" />
  <input type="submit" />
</form>
</code></pre>

And this action:

<pre><code>
 class SessionsController < ApplicationController
  def baz
    render :text => "#{request.request_uri}<br/>#{params.inspect}"
  end
 end
</code></pre>

Submitting the form yields this output:

<pre><code>
/sessions/baz
{"action"=>"baz", "foo"=>"bar", "controller"=>"sessions"}
</code></pre>

This spec:

<pre><code>
describe SessionsController do
 it "should not append params to POST" do
  post :baz, :foo => :bar
  request.request_uri.should == "/sessions/baz"
 end
end
</code></pre>

Fail with this message:

<pre><code>
expected: "/sessions/baz",
     got: "/sessions/baz?foo=bar" (using ==)
</code></pre>

Notice how in the real app, rails properly interprets the request.request_uri, but in rspec_on_rails, the POST parameters are appended to the request_uri like GET paramaters. 

This is a bug because the spec does not correctly represent the behavior of rails.  I came up against this as I was trying to write a redirect that was based on the url of a page that was posted to, i.e.:

User posts form
Site recognizes that user is not logged in
Site redirects to login page, but stores params and request_uri
After login, repost the params to the request_uri

And I couldn't find a way to spec that.

----------------------------------------------------------------------

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-02 11:26

Message:
s/but/bug

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-02 11:25

Message:
RSpec controller specs wrap Rails functional tests, which handle this request.

Here's a similar test in Rails:

  def test_should_not_append_params_to_post
    post :baz, :foo => :bar
    assert_equal "/sessions/baz", @request.request_uri
  end

And here's the output:

  <"/sessions/baz"> expected but was
  <"/sessions/baz?foo=bar">.

I'd recommend posting this but to the Rails tracker.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=15282&group_id=797

From noreply at rubyforge.org  Fri Nov  2 19:07:25 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri,  2 Nov 2007 19:07:25 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-15306 ] Updated Docs for
	http/svn installation
Message-ID: <20071102230725.80A4618585E3@rubyforge.org>

Feature Requests item #15306, was opened at 2007-11-02 23:07
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=15306&group_id=797

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: Updated Docs for http/svn installation

Initial Comment:

We should update the documentation at http://rspec.rubyforge.org/documentation/rails/install.html to use the http protocol (over svn) if one cannot access the svn protocol directly (instead of getting the tarballs from source).

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=15306&group_id=797

From noreply at rubyforge.org  Sat Nov  3 02:02:06 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat,  3 Nov 2007 02:02:06 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-15306 ] Updated Docs for
	http/svn installation
Message-ID: <20071103060206.93F8F18585B8@rubyforge.org>

Feature Requests item #15306, was opened at 2007-11-02 23:07
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=15306&group_id=797

Category: None
Group: None
>Status: Closed
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: Updated Docs for http/svn installation

Initial Comment:

We should update the documentation at http://rspec.rubyforge.org/documentation/rails/install.html to use the http protocol (over svn) if one cannot access the svn protocol directly (instead of getting the tarballs from source).

----------------------------------------------------------------------

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-03 06:02

Message:
It's already changed in trunk - we just haven't been updating the website between releases.

Coming soon ...

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=15306&group_id=797

From noreply at rubyforge.org  Mon Nov  5 15:13:25 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon,  5 Nov 2007 15:13:25 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15364 ] if all examples are pending,
	exceptions in 'before' block are not shown
Message-ID: <20071105201325.63C9D18585F9@rubyforge.org>

Bugs item #15364, was opened at 2007-11-05 13:13
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=15364&group_id=797

Category: expectation module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Chad Woolley (thewoolleyman)
Assigned to: Nobody (None)
Summary: if all examples are pending, exceptions in 'before' block are not shown

Initial Comment:
This is with trunk.  To reproduce:

1. make a spec with a single pending example
2. make a before block with an exception
3. run it - there are no errors reported, but return code ($?) is nonzero
4. Add a dummy non-pending example
5. run again - now you see the error reported

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=15364&group_id=797

From noreply at rubyforge.org  Mon Nov  5 17:48:58 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon,  5 Nov 2007 17:48:58 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-13943 ] ProfileFormatter (Top 10
	slowest examples)
Message-ID: <20071105224858.21C8C197811F@rubyforge.org>

Patches item #13943, was opened at 2007-09-14 17:44
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13943&group_id=797

Category: runner module
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Ian Leitch (idl)
>Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: ProfileFormatter (Top 10 slowest examples)

Initial Comment:
At work we have roughly 1600 examples, and they take about 45 seconds to run; a bit too long.

Upgrading from 1.0.5 to 1.0.8 actually almost doubled the time it takes for our specs to run, though I haven't had the time to investigate what particular change (s) introduced the new overhead.

In an attempt to improve this situation, I've created a simple formatter (attached) that times each example and produces a list of the 10 slowest. It turns out that our slowest examples are in the 0.4 seconds range, way too slow for a single example. Unsurprisingly, most of them are Rails view specs, and I suspect the rendering and response body parsing is to blame here. I plan to investigate this further down the stack and see if there is any low hanging fruit to be had.

Cheers
Ian Leitch

----------------------------------------------------------------------

>Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-11-05 17:48

Message:
Applied in r2815.
This supercedes http://rubyforge.org/tracker/index.php?func=detail&aid=14402&group_id=797&atid=3151 - which has been reverted in favour of this patch.

----------------------------------------------------------------------

Comment By: Ian Leitch (idl)
Date: 2007-09-17 12:09

Message:
What do you guys think about committing this, anything you
want changing?

----------------------------------------------------------------------

Comment By: Ian Leitch (idl)
Date: 2007-09-15 04:47

Message:
It extends ProgressBarFormatter just to give the user some
indication of progress while it's running.

----------------------------------------------------------------------

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-09-14 23:26

Message:
Very nice. A small comment - why is it extending ProgressBarFormatter?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13943&group_id=797

From noreply at rubyforge.org  Mon Nov  5 17:50:28 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon,  5 Nov 2007 17:50:28 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-14402 ] Add --profile option to show
	example options in specdoc
Message-ID: <20071105225028.75BC9197811F@rubyforge.org>

Patches item #14402, was opened at 2007-10-03 03:03
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14402&group_id=797

Category: None
Group: None
Status: Closed
>Resolution: Rejected
Priority: 3
Submitted By: Bryan Helmkamp (brynary)
>Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: Add --profile option to show example options in specdoc

Initial Comment:
Implementation of http://rubyforge.org/tracker/index.php?func=detail&aid=13206&group_id=797&atid=3152

----------------------------------------------------------------------

>Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-11-05 17:50

Message:
Similar functionality was implemented in http://rubyforge.org//tracker/index.php?func=detail&aid=13943&group_id=797&atid=3151 - which I liked better, so this patch has been reverted. Thanks anyway.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-18 21:17

Message:
Applied to r2740

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14402&group_id=797

From noreply at rubyforge.org  Mon Nov  5 17:58:42 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon,  5 Nov 2007 17:58:42 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-14042 ] Make DRB runner fall back to
	command line if no DRB server is present
Message-ID: <20071105225842.1EA89197811F@rubyforge.org>

Patches item #14042, was opened at 2007-09-18 11:02
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14042&group_id=797

Category: runner module
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 3
Submitted By: Mike Mangino (mmangino)
>Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: Make DRB runner fall back to command line if no DRB server is present

Initial Comment:
In projects with a CI builder it is nice to have the tests run even without the drb server running. This patches changes the DRB runner to fall back to the command line runner if there is no DRB server running.



----------------------------------------------------------------------

>Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-11-05 17:58

Message:
If I tell RSpec to run with drb and there is no drb server, I want to know about that - and I want to know it by seeing a big ugly failure. Sorry, don't like this one.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14042&group_id=797

From noreply at rubyforge.org  Mon Nov  5 18:01:13 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon,  5 Nov 2007 18:01:13 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-12054 ] rake task for spec:recent
Message-ID: <20071105230113.D95771D7801E@rubyforge.org>

Patches item #12054, was opened at 2007-07-06 14:09
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12054&group_id=797

Category: rails plugin
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 3
Submitted By: Jerrett Taylor (ennoia)
Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: rake task for spec:recent 

Initial Comment:
This is pretty simple, but i found it missing once i started to accumulate lots of specs



----------------------------------------------------------------------

>Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-11-05 18:01

Message:
Sorry, this is to naive - it doesn't do a good enough job of detecting twins. Plus, autotest is also here to do this better for us.

----------------------------------------------------------------------

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-07-10 11:55

Message:
Great idea. The logic you have to detect twins between lib and spec files is also implemented in RSpec's autotest plugin and in RSpec.tmbundle. I'd like to consolidate this to one place before I apply this, and just rely on one such mechanism from anywhere.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12054&group_id=797

From noreply at rubyforge.org  Mon Nov  5 18:06:59 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon,  5 Nov 2007 18:06:59 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-13777 ] run last example action in
	textmate bundle
Message-ID: <20071105230659.953DC1858598@rubyforge.org>

Patches item #13777, was opened at 2007-09-08 14:13
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13777&group_id=797

Category: RSpec.tmbundle
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jeremy Stell-Smith (stellsmi)
Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: run last example action in textmate bundle

Initial Comment:
This patch records every action you do in the textmate plugin and will rerun it.

For example, go to a file, run a spec, go to a different file, and then cmd-shift-i, the last spec will be run

----------------------------------------------------------------------

>Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-11-05 18:06

Message:
I'll apply this if you add examples for the bundle itself... We have pretty good coverage for the spec (except for some cocoa and osascript stuff) and I don't want to see it drop.

----------------------------------------------------------------------

Comment By: Jeremy Stell-Smith (stellsmi)
Date: 2007-10-04 17:51

Message:
I added it a while back,

----------------------------------------------------------------------

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-09-08 17:46

Message:
You forgot to check the box when attaching the patch Jeremy :-/

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13777&group_id=797

From noreply at rubyforge.org  Mon Nov  5 18:08:09 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon,  5 Nov 2007 18:08:09 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-8303 ] :nil_object option for mocks
Message-ID: <20071105230809.2C55E1858595@rubyforge.org>

Patches item #8303, was opened at 2007-01-30 02:04
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8303&group_id=797

Category: mock module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Chris Anderson (jchris)
Assigned to: Nobody (None)
Summary: :nil_object option for mocks

Initial Comment:
A nil object returns nil (rather than itself) for any methods which aren't stubbed.

This is useful if you are going to send something into views, and don't care how it renders, but don't want errors.

----------------------------------------------------------------------

>Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-11-05 18:08

Message:
I think we should reject this. I don't see what it's good for.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-02 20:21

Message:
This is a couple of months old now. Anybody have thoughts about :null_object => :returns_nil?

How about :default => any_return_value?????

Then you could say :default => nil, but you could also say :default => "" in the case of views, etc.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-02 06:49

Message:
This is not implemented. We have :null_object => true, which causes the mock to return itself for any unexpected calls. This request is for a way to get it to return nil.

----------------------------------------------------------------------

Comment By: Michael Klishin (michaelklishin)
Date: 2007-08-02 06:13

Message:
Hey, isn't this one already applied? Should we cleanup patches and bugs a bit?

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-01-30 13:43

Message:
Why don't you go ahead and float this on the lists. I like the idea in general, though there's no syntax for it that is standing out for me at the moment.

Cheers,
David

----------------------------------------------------------------------

Comment By: Chris Anderson (jchris)
Date: 2007-01-30 12:09

Message:
I've been using nil objects as an implementation in Ruby of the null object 
pattern for a while now. Both approaches have their uses, depending on the 
client code.

You're right, the RSpec API for the nil object could have a more transparent 
usage that reflects its status as a variant on the null object pattern. Maybe as 
an alternative value for :null_object. My first thought would be 

mock('returns nil for all unstubbed methods', :null_object => :returns_nil)

This keeps the surface area of mocks down, and presents the "nil object" as a 
special case of null object.

Thoughts? Should I bring this up on the mailing list? Once we figure out the 
API, I'll be happy to provide a patch.

----------------------------------------------------------------------

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-01-30 07:18

Message:
The term "null object" refers to a design pattern (google it).
There is no "nil object" design pattern.

I'm a little concerned that the presence of :null_object and :nil_object may be confusing for users since they sound so similar. One is the implementation of a design pattern, the other is ehm, something else.

Can we come up with a less confusing name?


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8303&group_id=797

From noreply at rubyforge.org  Mon Nov  5 18:08:54 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon,  5 Nov 2007 18:08:54 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-13607 ] README for running stories
Message-ID: <20071105230854.C937A1858598@rubyforge.org>

Patches item #13607, was opened at 2007-09-02 19:12
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13607&group_id=797

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Ian Dees (undees)
Assigned to: Nobody (None)
Summary: README for running stories

Initial Comment:
I'm attaching a simple README to go in the examples/story directory and explain the basics of running stories (both the provided game-of-life ones and the reader's own).



----------------------------------------------------------------------

>Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-11-05 18:08

Message:
Isn't this outdated now?

----------------------------------------------------------------------

Comment By: Ian Dees (undees)
Date: 2007-09-02 19:13

Message:
It's a patch against r2492, btw.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13607&group_id=797

From noreply at rubyforge.org  Mon Nov  5 18:16:09 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon,  5 Nov 2007 18:16:09 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-13607 ] README for running stories
Message-ID: <20071105231609.EACC81858595@rubyforge.org>

Patches item #13607, was opened at 2007-09-02 23:12
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13607&group_id=797

Category: None
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 3
Submitted By: Ian Dees (undees)
>Assigned to: David Chelimsky (dchelimsky)
Summary: README for running stories

Initial Comment:
I'm attaching a simple README to go in the examples/story directory and explain the basics of running stories (both the provided game-of-life ones and the reader's own).



----------------------------------------------------------------------

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-05 23:16

Message:
Yes - outdated and also doesn't really capture the spirit of what we're trying to do. Stories are not just another way to express examples - they're a completely different animal.

Thanks for the effort though.

----------------------------------------------------------------------

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-11-05 23:08

Message:
Isn't this outdated now?

----------------------------------------------------------------------

Comment By: Ian Dees (undees)
Date: 2007-09-02 23:13

Message:
It's a patch against r2492, btw.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13607&group_id=797

From noreply at rubyforge.org  Mon Nov  5 18:16:25 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon,  5 Nov 2007 18:16:25 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-14082 ] [PATCH] allow stubs to yield
	and return values
Message-ID: <20071105231625.A58A01858595@rubyforge.org>

Patches item #14082, was opened at 2007-09-19 17:30
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14082&group_id=797

Category: mock module
Group: None
Status: Open
>Resolution: Accepted
Priority: 3
Submitted By: Pat Maddox (pergesu)
Assigned to: Nobody (None)
Summary: [PATCH] allow stubs to yield and return values

Initial Comment:
Passing blocks to a builder method is a common pattern.  For example:

    new_workflow = build(:name => "Default") do |w|
      w.add_step :name => "description"
      w.add_step :name => "screenshot_selection"
      w.add_step :name => "preview"
    end

This patch lets you stub a method and specify the object to yield and the object to return.  It's just a chained and_yield(foo).and_return(bar)

@new_workflow = mock_model(Workflow, :add_step => true)
Workflow.stub!(:build).and_yield(@new_workflow).and_return @new_workflow

----------------------------------------------------------------------

>Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-11-05 18:16

Message:
This causes the following error in r2814:

1)
'a Mock expectation should use block for expectation if provided' FAILED
expected: "booh",
     got: nil (using ==)
./spec/spec/mocks/mock_spec.rb:101:

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14082&group_id=797

From noreply at rubyforge.org  Mon Nov  5 18:16:47 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon,  5 Nov 2007 18:16:47 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-8303 ] :nil_object option for mocks
Message-ID: <20071105231647.6F06E1858595@rubyforge.org>

Patches item #8303, was opened at 2007-01-30 07:04
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8303&group_id=797

Category: mock module
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 3
Submitted By: Chris Anderson (jchris)
Assigned to: Nobody (None)
Summary: :nil_object option for mocks

Initial Comment:
A nil object returns nil (rather than itself) for any methods which aren't stubbed.

This is useful if you are going to send something into views, and don't care how it renders, but don't want errors.

----------------------------------------------------------------------

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-05 23:16

Message:
Agreed.

----------------------------------------------------------------------

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-11-05 23:08

Message:
I think we should reject this. I don't see what it's good for.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-03 00:21

Message:
This is a couple of months old now. Anybody have thoughts about :null_object => :returns_nil?

How about :default => any_return_value?????

Then you could say :default => nil, but you could also say :default => "" in the case of views, etc.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-02 10:49

Message:
This is not implemented. We have :null_object => true, which causes the mock to return itself for any unexpected calls. This request is for a way to get it to return nil.

----------------------------------------------------------------------

Comment By: Michael Klishin (michaelklishin)
Date: 2007-08-02 10:13

Message:
Hey, isn't this one already applied? Should we cleanup patches and bugs a bit?

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-01-30 18:43

Message:
Why don't you go ahead and float this on the lists. I like the idea in general, though there's no syntax for it that is standing out for me at the moment.

Cheers,
David

----------------------------------------------------------------------

Comment By: Chris Anderson (jchris)
Date: 2007-01-30 17:09

Message:
I've been using nil objects as an implementation in Ruby of the null object 
pattern for a while now. Both approaches have their uses, depending on the 
client code.

You're right, the RSpec API for the nil object could have a more transparent 
usage that reflects its status as a variant on the null object pattern. Maybe as 
an alternative value for :null_object. My first thought would be 

mock('returns nil for all unstubbed methods', :null_object => :returns_nil)

This keeps the surface area of mocks down, and presents the "nil object" as a 
special case of null object.

Thoughts? Should I bring this up on the mailing list? Once we figure out the 
API, I'll be happy to provide a patch.

----------------------------------------------------------------------

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-01-30 12:18

Message:
The term "null object" refers to a design pattern (google it).
There is no "nil object" design pattern.

I'm a little concerned that the presence of :null_object and :nil_object may be confusing for users since they sound so similar. One is the implementation of a design pattern, the other is ehm, something else.

Can we come up with a less confusing name?


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8303&group_id=797

From noreply at rubyforge.org  Mon Nov  5 19:10:09 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon,  5 Nov 2007 19:10:09 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-14023 ] Small optimization for
	heavily proxied objects.
Message-ID: <20071106001009.32FD0197811E@rubyforge.org>

Patches item #14023, was opened at 2007-09-17 18:22
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14023&group_id=797

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Ian Leitch (idl)
Assigned to: Nobody (None)
Summary: Small optimization for heavily proxied objects.

Initial Comment:
This patch provides roughly a 2% speed-up for my test suite. In situations where objects are heavily proxied it should help more.

By the way, this isn't the level of optimization I hope to contribute in the future, I simply stumbled across it when reading the source to create my earlier optimization patch.

Cheers
Ian Leitch

----------------------------------------------------------------------

>Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-11-05 19:10

Message:
Applied in r2817.

Btw, how do you measure a 2% speed-up??

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14023&group_id=797

From noreply at rubyforge.org  Mon Nov  5 19:10:28 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon,  5 Nov 2007 19:10:28 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-14023 ] Small optimization for
	heavily proxied objects.
Message-ID: <20071106001028.AE1B7197811E@rubyforge.org>

Patches item #14023, was opened at 2007-09-17 18:22
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14023&group_id=797

>Category: mock module
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Ian Leitch (idl)
>Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: Small optimization for heavily proxied objects.

Initial Comment:
This patch provides roughly a 2% speed-up for my test suite. In situations where objects are heavily proxied it should help more.

By the way, this isn't the level of optimization I hope to contribute in the future, I simply stumbled across it when reading the source to create my earlier optimization patch.

Cheers
Ian Leitch

----------------------------------------------------------------------

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-11-05 19:10

Message:
Applied in r2817.

Btw, how do you measure a 2% speed-up??

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14023&group_id=797

From noreply at rubyforge.org  Mon Nov  5 19:33:36 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon,  5 Nov 2007 19:33:36 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-14023 ] Small optimization for
	heavily proxied objects.
Message-ID: <20071106003336.5671F1858611@rubyforge.org>

Patches item #14023, was opened at 2007-09-17 22:22
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14023&group_id=797

Category: mock module
Group: None
Status: Closed
Resolution: Accepted
Priority: 3
Submitted By: Ian Leitch (idl)
Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: Small optimization for heavily proxied objects.

Initial Comment:
This patch provides roughly a 2% speed-up for my test suite. In situations where objects are heavily proxied it should help more.

By the way, this isn't the level of optimization I hope to contribute in the future, I simply stumbled across it when reading the source to create my earlier optimization patch.

Cheers
Ian Leitch

----------------------------------------------------------------------

Comment By: Ian Leitch (idl)
Date: 2007-11-06 00:33

Message:
I was seeing a slight improvement with individual tests. I did about 5 runs of each and took and average.. not very scientific. I'm confident an object with enough proxies would show definite speed improvement; this patch is similar to my other optimization patch.

----------------------------------------------------------------------

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-11-06 00:10

Message:
Applied in r2817.

Btw, how do you measure a 2% speed-up??

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14023&group_id=797

From noreply at rubyforge.org  Mon Nov  5 19:33:54 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon,  5 Nov 2007 19:33:54 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-13454 ] disabled specs (e.g.
	xit)
Message-ID: <20071106003354.D1626185861B@rubyforge.org>

Feature Requests item #13454, was opened at 2007-08-28 07:51
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13454&group_id=797

Category: runner module
Group: None
>Status: Closed
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: disabled specs (e.g. xit)

Initial Comment:
I ran into a situation where a pending spec was not sufficient.
It was useful to create an xit method that deactivated the spec and gave a warning that the spec was deactivated.

It would be very nice to have xit (or equivalent method) because:
* There are situations where a spec just needs to be xed out for a moment. This is not meant to be checked in. Its a good backup when focused specs do not reliably work, such as when working on rspec core.
* Sticking a pending in front of every spec requires too much mental effort. i.e.  I lost the context of the problem I was working on because I needed to figure out the regex. Its really annoying.
* Pending is not meant to temporarily disable specs
* Its an xUnit convention
* test/spec uses xspecify (for pending specs, which is not the same)
* I feel silly having a useful method lying around that I can't check in (well I did check it in again, and since removed it)
* Its the simplest thing that could possibly work
* The alternative is commenting out the specs

I'm open to names other than xit, such as disabled_it. If we are afraid of confusing users, it could be deemed an "advanced" feature.

I understand that its difficult to justify because it involves a process that not commited to the repository, yet it is a common practice and useful.

----------------------------------------------------------------------

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-06 00:33

Message:
This was implemented a while back.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-30 16:38

Message:
+1 for BehaviourDisabledError or ExampleDisabledError

----------------------------------------------------------------------

Comment By: Brian Takita (btakita)
Date: 2007-08-30 16:31

Message:
I propose raising an error (e.g. raise
BehaviourDisabledError, "Behaviour blah blah is disabled").
This has different semantic meaning and usage from pending.
Pending can be checked in, xit cannot.

Also, to clarify, xtest in an xUnit convention (by practical
usage). It naturally works because tests are methods and you
can change the method name. I meant, xit is rspec's
equivalent to xtest.
I have been in several situations where the developer is new
to rspec and experienced with xUnit expects to be able to x
out the examples.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-28 20:40

Message:
Maybe I misunderstood the goal here. My thinking is that xit is a shortcut for pending - it should work exactly like pending does, providing its own message - so that it does keep it on the radar. I agree w/ Brian's goal of being able to swiftly switch the state of each "it" by preceding it w/ an 'x', but only if it makes sure you know about it.

----------------------------------------------------------------------

Comment By: Dan North (tastapod)
Date: 2007-08-28 20:28

Message:
David said: "I've been known to accidentally check one in from time to time. If this helps to keep things on the radar, then it's a good thing."

The problem is, it doesn't keep it on the radar. I've found literally tens of tests commented out (or x-ed out) in a codebase, which once they were re-enabled all failed because the code no longer did what it was supposed to.

The intent behind pending() is to keep them on the radar, nagging away with every build, but without actually failing the build. You can put a pending in a describe (specify) block and it should Just Work (ie. mark the whole section and any of its examples as pending). If not this is a bug.

I'd like to challenge two of the comments in the original description. Firstly pending is exactly intended to temporarily disable examples or scenarios - that's the point! Secondly, it isn't a convention from xunit, it's a convention from jbehave - the java bdd framework - that I introduced because I didn't like the binary nature of red/green (I guess I wanted yellow!). Pending behaviour is very much a BDD initiative, although it's made its way back into the xunit world (nunit has it as an Ignore attribute on a Test).

Then I brought it into rbehave because I found it so useful - and because scenarios tend to spend longer in a "pending" state than code-level examples. Then one of the rspec devs (I think it was Brian) brought it into rspec and improved it by allowing it to wrap a block.

I would strongly encourage using pending() for exactly this use case. Ideally with a message saying what needs to be done to make it work.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-28 17:06

Message:
For me, RSpec is all about process. So even though I was originally resistant to this, the more I think about it the more I can see using it. I comment specs out all the time in practice and I've been known to accidentally check one in from time to time. If this helps to keep things on the radar, then it's a good thing.

I say go for it - but the docs should be very specific about intent (i.e. recommend that xit should not be committed).

----------------------------------------------------------------------

Comment By: Ian Dees (undees)
Date: 2007-08-28 16:04

Message:
Just playing devil's advocate here, but couldn't you accomplish the same by just pasting "; pending 'x'" at the end of the "it" line, like this?

describe Foo
  it 'should be baz' do; pending 'x'
    @foo.should == 'baz'
  end
end



----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13454&group_id=797

From noreply at rubyforge.org  Mon Nov  5 19:34:24 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon,  5 Nov 2007 19:34:24 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15372 ] spec command with no args
	doesn't output anything
Message-ID: <20071106003425.144F21858611@rubyforge.org>

Bugs item #15372, was opened at 2007-11-05 19:34
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=15372&group_id=797

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Aslak Helles?y (aslak_hellesoy)
Assigned to: Nobody (None)
Summary: spec command with no args doesn't output anything

Initial Comment:
In r2816

ruby bin/spec

(no output at all - it used to output the help text)

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=15372&group_id=797

From noreply at rubyforge.org  Mon Nov  5 19:51:19 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon,  5 Nov 2007 19:51:19 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-15373 ] Rspec In Spanish
Message-ID: <20071106005119.E8F3E18585F7@rubyforge.org>

Feature Requests item #15373, was opened at 2007-11-06 00:51
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=15373&group_id=797

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: raimond garcia (voodoorai2000)
Assigned to: Nobody (None)
Summary: Rspec In Spanish

Initial Comment:
Hi,

rSpec, really cool, using it at my current job and will continue to use it and promote the good word.  To help me in my endeavors, it would be great if there was language support.  

See, it makes a lot of sense to read a Story using Given, When, And, Then, but if I could write the story as Cuando, Si, Y, Entonces, that would be much more appealing documentation for my boss and easier to catch on to from my developer colleagues that do not speak that much English.

Sincerely,


Raimond Garcia

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=15373&group_id=797

From noreply at rubyforge.org  Mon Nov  5 19:58:34 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon,  5 Nov 2007 19:58:34 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-15373 ] Rspec In Spanish
Message-ID: <20071106005834.CD4DF18585B3@rubyforge.org>

Feature Requests item #15373, was opened at 2007-11-06 00:51
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=15373&group_id=797

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: raimond garcia (voodoorai2000)
Assigned to: Nobody (None)
Summary: Rspec In Spanish

Initial Comment:
Hi,

rSpec, really cool, using it at my current job and will continue to use it and promote the good word.  To help me in my endeavors, it would be great if there was language support.  

See, it makes a lot of sense to read a Story using Given, When, And, Then, but if I could write the story as Cuando, Si, Y, Entonces, that would be much more appealing documentation for my boss and easier to catch on to from my developer colleagues that do not speak that much English.

Sincerely,


Raimond Garcia

----------------------------------------------------------------------

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-06 00:58

Message:
We should set up some way to configure things so that you could choose the words you want to use for Story/Scenario/Given/When/Then/And.

I don't think we should have implicit support for any language other than English unless we're going to support them all :)


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=15373&group_id=797

From noreply at rubyforge.org  Mon Nov  5 20:45:08 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon,  5 Nov 2007 20:45:08 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-13607 ] README for running stories
Message-ID: <20071106014508.488BA18585EE@rubyforge.org>

Patches item #13607, was opened at 2007-09-02 16:12
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13607&group_id=797

Category: None
Group: None
Status: Closed
Resolution: Rejected
Priority: 3
Submitted By: Ian Dees (undees)
Assigned to: David Chelimsky (dchelimsky)
Summary: README for running stories

Initial Comment:
I'm attaching a simple README to go in the examples/story directory and explain the basics of running stories (both the provided game-of-life ones and the reader's own).



----------------------------------------------------------------------

>Comment By: Ian Dees (undees)
Date: 2007-11-05 17:45

Message:
You're right, it is outdated and in some ways imprecise.  At the time, it was 
supposed to be enough to get people from a command prompt to being able 
to run the stories that ship with RSpec (it wasn't at all obvious how to do this 
in the early days of the RBehave -> RSpec migration).  But the Story Runner 
has changed a lot since then.

Do we still need a README for the sample stories?  Or is it obvious how to 
run the them now?  I'd be happy to take a second crack at it, and include both 
a updated info and a better explanation of what stories are than what I had 
before.

Why don't I open up a shared doc on some newfangled collaborative site, 
correct my previous errors, temper it in the fire of public scrutiny, and submit 
as a new patch after it's passed muster?  That would reduce the risk of a 
months-old patch languishing into irrelevancy.



----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-05 15:16

Message:
Yes - outdated and also doesn't really capture the spirit of what we're trying to do. Stories are not just another way to express examples - they're a completely different animal.

Thanks for the effort though.

----------------------------------------------------------------------

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-11-05 15:08

Message:
Isn't this outdated now?

----------------------------------------------------------------------

Comment By: Ian Dees (undees)
Date: 2007-09-02 16:13

Message:
It's a patch against r2492, btw.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13607&group_id=797

From noreply at rubyforge.org  Mon Nov  5 20:48:41 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon,  5 Nov 2007 20:48:41 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-13607 ] README for running stories
Message-ID: <20071106014841.CB2C818585E2@rubyforge.org>

Patches item #13607, was opened at 2007-09-02 23:12
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13607&group_id=797

Category: None
Group: None
Status: Closed
Resolution: Rejected
Priority: 3
Submitted By: Ian Dees (undees)
Assigned to: David Chelimsky (dchelimsky)
Summary: README for running stories

Initial Comment:
I'm attaching a simple README to go in the examples/story directory and explain the basics of running stories (both the provided game-of-life ones and the reader's own).



----------------------------------------------------------------------

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-06 01:48

Message:
Ian - you're absolutely welcome to take another crack at it! Go about it as you wish and reopen this ticket when you're ready.

----------------------------------------------------------------------

Comment By: Ian Dees (undees)
Date: 2007-11-06 01:45

Message:
You're right, it is outdated and in some ways imprecise.  At the time, it was 
supposed to be enough to get people from a command prompt to being able 
to run the stories that ship with RSpec (it wasn't at all obvious how to do this 
in the early days of the RBehave -> RSpec migration).  But the Story Runner 
has changed a lot since then.

Do we still need a README for the sample stories?  Or is it obvious how to 
run the them now?  I'd be happy to take a second crack at it, and include both 
a updated info and a better explanation of what stories are than what I had 
before.

Why don't I open up a shared doc on some newfangled collaborative site, 
correct my previous errors, temper it in the fire of public scrutiny, and submit 
as a new patch after it's passed muster?  That would reduce the risk of a 
months-old patch languishing into irrelevancy.



----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-05 23:16

Message:
Yes - outdated and also doesn't really capture the spirit of what we're trying to do. Stories are not just another way to express examples - they're a completely different animal.

Thanks for the effort though.

----------------------------------------------------------------------

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-11-05 23:08

Message:
Isn't this outdated now?

----------------------------------------------------------------------

Comment By: Ian Dees (undees)
Date: 2007-09-02 23:13

Message:
It's a patch against r2492, btw.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13607&group_id=797

From noreply at rubyforge.org  Mon Nov  5 20:50:26 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon,  5 Nov 2007 20:50:26 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-12163 ]
	spec:ui:selenium:start and spec:ui:selenium:stop
Message-ID: <20071106015026.3341018585A2@rubyforge.org>

Feature Requests item #12163, was opened at 2007-07-10 16:48
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12163&group_id=797

Category: None
Group: None
>Status: Closed
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: spec:ui:selenium:start and spec:ui:selenium:stop

Initial Comment:
It would be nice to have these rake tasks to stop and start selenium-server just as we start and top spec_server.

----------------------------------------------------------------------

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-06 01:50

Message:
spec:ui has moved to another project - closing this

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12163&group_id=797

From undees at gmail.com  Mon Nov  5 22:06:13 2007
From: undees at gmail.com (Ian Dees)
Date: Mon, 5 Nov 2007 19:06:13 -0800
Subject: [rspec-devel] Stories vs. examples
Message-ID: <ad4f9af90711051906j109c6560k6a21e84514b54c40@mail.gmail.com>

Hi, all.

I'm posting a philosophical question here, rather than cluttering up
the tracker for the patch where it originated.

Quoth David, in response to some fuzzy thinking on my part:

> Stories are not just another way to express examples - they're a completely different animal.

The offending clause of mine: "stories are another way to write your
tests.... examples are meant for small, targeted descriptions of your
code's behavior... stories are suited to longer, more detailed
narratives."

The intent wasn't to say that stories are a different syntax for
examples; it was that stories and examples are two different syntaxes
for two different test-writing purposes.  But now I'm wondering if I
even have _that_ right.

In Rails-land, the distinction is much clearer: you typically see
examples for testing code, and stories for testing applications (in
the blog posts I've read, anyway).

But in GUI-land, the picture blurs a great deal: you're always testing
applications, but sometimes you're giving a tiny example of how one
feature works, and at other times you're writing a story about several
steps of an interaction between the customer and the UI.

Anyone want to jump into these muddy waters?

From noreply at rubyforge.org  Tue Nov  6 08:11:06 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue,  6 Nov 2007 08:11:06 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-15373 ] Rspec In Spanish
Message-ID: <20071106131106.4A61218585A5@rubyforge.org>

Feature Requests item #15373, was opened at 2007-11-06 00:51
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=15373&group_id=797

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: raimond garcia (voodoorai2000)
Assigned to: Nobody (None)
Summary: Rspec In Spanish

Initial Comment:
Hi,

rSpec, really cool, using it at my current job and will continue to use it and promote the good word.  To help me in my endeavors, it would be great if there was language support.  

See, it makes a lot of sense to read a Story using Given, When, And, Then, but if I could write the story as Cuando, Si, Y, Entonces, that would be much more appealing documentation for my boss and easier to catch on to from my developer colleagues that do not speak that much English.

Sincerely,


Raimond Garcia

----------------------------------------------------------------------

>Comment By: raimond garcia (voodoorai2000)
Date: 2007-11-06 13:11

Message:
Hi Dave,

That sounds great to me, maybe some sort of rspec configuration file, very 
basic but powerful.  Just by being able to alias methods with whatever is more 
appropriate would be great.  

Developers have to learn English to keep up with the latest techniques but 
employers don't.  And it will definitely make a difference to show the 
specs/stories/documentation of their app in their native language.

Looking forward to hearing more about this feature.

Thanks!

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-06 00:58

Message:
We should set up some way to configure things so that you could choose the words you want to use for Story/Scenario/Given/When/Then/And.

I don't think we should have implicit support for any language other than English unless we're going to support them all :)


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=15373&group_id=797

From tastapod at gmail.com  Tue Nov  6 08:43:23 2007
From: tastapod at gmail.com (Dan North)
Date: Tue, 6 Nov 2007 13:43:23 +0000
Subject: [rspec-devel] Stories vs. examples
In-Reply-To: <ad4f9af90711051906j109c6560k6a21e84514b54c40@mail.gmail.com>
References: <ad4f9af90711051906j109c6560k6a21e84514b54c40@mail.gmail.com>
Message-ID: <d559d8430711060543g5d8954fbu157afcc177e847a1@mail.gmail.com>

Hi Ian.

I find it helps to think about the audience for your documentation. (It is
documentation after all, it just happens to run, which is rather nice.)

For the specs, the audience is developers. They want to know what an object
of a particular type - or more specifically in a particular role - does,
which other objects it interacts with and why. This audience wants to see
progress without leaving their IDE or editor, which is why we put effort
into making TextMate plugins and why we want to play nice with all the
Test::Unit runners.

For the stories, the audience is testers, analysts and ultimately the
various stakeholders who are requesting the features. They want to know what
the system does and how to interact with it to get work done. They don't
really care what happens under the hood. Typically they are non-technical
(or less technical than developers) which is why we think there is so much
value in making their documentation look like documentation - just plain
words on a page. Even better, if you can give them green words on a page
when the feature is implemented and working, or red words on a page when the
feature isn't working, or grey words for unimplemented features, they can
see progress in a living document. Now make that document editable, like a
regular document, and you are well on your way to acceptance testing
Nirvana.

So the process (described as "outside in" as opposed to "top down" or
"bottom up") starts by expressing a feature request as a story, driving out
the scenarios that define "done" for that story and automating the steps
that make up the scenarios. Then you use code-level examples to drive
inwards (that word "drive" again) from the outermost objects that the steps
identified. All the time you want to implement just enough behaviour to get
the steps to work, to drive the scenarios. Then you're done and you go to
the pub for a well-earned drink. Hence "beer-driven development".

Hope that helps,
Dan

On 11/6/07, Ian Dees <undees at gmail.com> wrote:
>
> Hi, all.
>
> I'm posting a philosophical question here, rather than cluttering up
> the tracker for the patch where it originated.
>
> Quoth David, in response to some fuzzy thinking on my part:
>
> > Stories are not just another way to express examples - they're a
> completely different animal.
>
> The offending clause of mine: "stories are another way to write your
> tests.... examples are meant for small, targeted descriptions of your
> code's behavior... stories are suited to longer, more detailed
> narratives."
>
> The intent wasn't to say that stories are a different syntax for
> examples; it was that stories and examples are two different syntaxes
> for two different test-writing purposes.  But now I'm wondering if I
> even have _that_ right.
>
> In Rails-land, the distinction is much clearer: you typically see
> examples for testing code, and stories for testing applications (in
> the blog posts I've read, anyway).
>
> But in GUI-land, the picture blurs a great deal: you're always testing
> applications, but sometimes you're giving a tiny example of how one
> feature works, and at other times you're writing a story about several
> steps of an interaction between the customer and the UI.
>
> Anyone want to jump into these muddy waters?
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20071106/ee8c7a82/attachment-0001.html 

From noreply at rubyforge.org  Tue Nov  6 09:11:59 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue,  6 Nov 2007 09:11:59 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15364 ] if all examples are pending,
	exceptions in 'before' block are not shown
Message-ID: <20071106141200.0A09918585FE@rubyforge.org>

Bugs item #15364, was opened at 2007-11-05 20:13
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=15364&group_id=797

Category: expectation module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Chad Woolley (thewoolleyman)
Assigned to: Nobody (None)
Summary: if all examples are pending, exceptions in 'before' block are not shown

Initial Comment:
This is with trunk.  To reproduce:

1. make a spec with a single pending example
2. make a before block with an exception
3. run it - there are no errors reported, but return code ($?) is nonzero
4. Add a dummy non-pending example
5. run again - now you see the error reported

----------------------------------------------------------------------

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-06 14:11

Message:
If there are no examples, then before(:each) shouldn't run, so that part of the behaviour is to be expected.

I think the problem here is the non-zero return code, so I'll leave this open until we resolve that.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=15364&group_id=797

From noreply at rubyforge.org  Tue Nov  6 10:10:38 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue,  6 Nov 2007 10:10:38 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15364 ] if all examples are pending,
	exceptions in 'before' block are not shown
Message-ID: <20071106151038.20453197811E@rubyforge.org>

Bugs item #15364, was opened at 2007-11-05 13:13
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=15364&group_id=797

Category: expectation module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Chad Woolley (thewoolleyman)
Assigned to: Nobody (None)
Summary: if all examples are pending, exceptions in 'before' block are not shown

Initial Comment:
This is with trunk.  To reproduce:

1. make a spec with a single pending example
2. make a before block with an exception
3. run it - there are no errors reported, but return code ($?) is nonzero
4. Add a dummy non-pending example
5. run again - now you see the error reported

----------------------------------------------------------------------

>Comment By: Chad Woolley (thewoolleyman)
Date: 2007-11-06 08:10

Message:
I think it IS running, though.  The dummy exception in
before, even though there are no examples, is what's causing
the nonzero return code.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-06 07:11

Message:
If there are no examples, then before(:each) shouldn't run, so that part of the behaviour is to be expected.

I think the problem here is the non-zero return code, so I'll leave this open until we resolve that.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=15364&group_id=797

From bkeepers at gmail.com  Tue Nov  6 10:15:52 2007
From: bkeepers at gmail.com (Brandon Keepers)
Date: Tue, 6 Nov 2007 10:15:52 -0500
Subject: [rspec-devel] spec_helper required multiple times
Message-ID: <051C7AD8-B9C1-4053-82A6-9321EE388E5F@gmail.com>

spec_helper gets run multiple times during a spec run.  Throw this at  
the bottom of spec_helper:

   @x ||= 0
   puts "requiring spec_helper: #{@x += 1}"

Is this expected behavior?  This seems to be caused by #require not  
expanding paths, so it requires spec_helper once per unique require  
statement (once per spec directory).

It is resolved by wrapping the require at the top of each spec file  
with expand_path:

   require File.expand_path(File.dirname(__FILE__) + '/../../ 
spec_helper')

It seems to me like this is something that require should do  
automatically.  Thoughts?

Brandon

From dchelimsky at gmail.com  Tue Nov  6 10:26:48 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 6 Nov 2007 09:26:48 -0600
Subject: [rspec-devel] spec_helper required multiple times
In-Reply-To: <051C7AD8-B9C1-4053-82A6-9321EE388E5F@gmail.com>
References: <051C7AD8-B9C1-4053-82A6-9321EE388E5F@gmail.com>
Message-ID: <57c63afe0711060726y474af106jd0fcb9181ffb2772@mail.gmail.com>

On Nov 6, 2007 9:15 AM, Brandon Keepers <bkeepers at gmail.com> wrote:
> spec_helper gets run multiple times during a spec run.  Throw this at
> the bottom of spec_helper:
>
>    @x ||= 0
>    puts "requiring spec_helper: #{@x += 1}"
>
> Is this expected behavior?  This seems to be caused by #require not
> expanding paths, so it requires spec_helper once per unique require
> statement (once per spec directory).
>
> It is resolved by wrapping the require at the top of each spec file
> with expand_path:
>
>    require File.expand_path(File.dirname(__FILE__) + '/../../
> spec_helper')
>
> It seems to me like this is something that require should do
> automatically.  Thoughts?

Do you mean that Ruby's require should do the right thing, that rspec
should patch require to do the right thing, or that users should do
the right thing?

>
> Brandon
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From bkeepers at gmail.com  Tue Nov  6 10:43:12 2007
From: bkeepers at gmail.com (Brandon Keepers)
Date: Tue, 6 Nov 2007 10:43:12 -0500
Subject: [rspec-devel] spec_helper required multiple times
In-Reply-To: <57c63afe0711060726y474af106jd0fcb9181ffb2772@mail.gmail.com>
References: <051C7AD8-B9C1-4053-82A6-9321EE388E5F@gmail.com>
	<57c63afe0711060726y474af106jd0fcb9181ffb2772@mail.gmail.com>
Message-ID: <4911A0DA-7544-4142-AFD1-E52602B3026D@gmail.com>


On Nov 6, 2007, at 10:26 AM, David Chelimsky wrote:

> On Nov 6, 2007 9:15 AM, Brandon Keepers <bkeepers at gmail.com> wrote:
>> spec_helper gets run multiple times during a spec run.  Throw this at
>> the bottom of spec_helper:
>>
>>   @x ||= 0
>>   puts "requiring spec_helper: #{@x += 1}"
>>
>> Is this expected behavior?  This seems to be caused by #require not
>> expanding paths, so it requires spec_helper once per unique require
>> statement (once per spec directory).
>>
>> It is resolved by wrapping the require at the top of each spec file
>> with expand_path:
>>
>>   require File.expand_path(File.dirname(__FILE__) + '/../../
>> spec_helper')
>>
>> It seems to me like this is something that require should do
>> automatically.  Thoughts?
>
> Do you mean that Ruby's require should do the right thing, that rspec
> should patch require to do the right thing, or that users should do
> the right thing?

Ideally I think Ruby's require should do the right thing, but that not  
being the case, I don't think rspec should change that behavior.  I  
guess rspec's generators should call expand_path, encouraging users to  
do the right thing.

I'll try to take this question farther upstream, but this issue  
primarily effects rspec and testunit in practice since they require  
the same file using different absolute paths, whereas other  
applications rely on the load path and relative paths.  Mainly I just  
wanted to bring it up to see if anyone had any insights as to why  
require works that way.

Brandon

From dchelimsky at gmail.com  Tue Nov  6 10:49:16 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 6 Nov 2007 09:49:16 -0600
Subject: [rspec-devel] spec_helper required multiple times
In-Reply-To: <4911A0DA-7544-4142-AFD1-E52602B3026D@gmail.com>
References: <051C7AD8-B9C1-4053-82A6-9321EE388E5F@gmail.com>
	<57c63afe0711060726y474af106jd0fcb9181ffb2772@mail.gmail.com>
	<4911A0DA-7544-4142-AFD1-E52602B3026D@gmail.com>
Message-ID: <57c63afe0711060749gbafe96cub3db3dae8d412d9c@mail.gmail.com>

On Nov 6, 2007 9:43 AM, Brandon Keepers <bkeepers at gmail.com> wrote:
>
> On Nov 6, 2007, at 10:26 AM, David Chelimsky wrote:
>
> > On Nov 6, 2007 9:15 AM, Brandon Keepers <bkeepers at gmail.com> wrote:
> >> spec_helper gets run multiple times during a spec run.  Throw this at
> >> the bottom of spec_helper:
> >>
> >>   @x ||= 0
> >>   puts "requiring spec_helper: #{@x += 1}"
> >>
> >> Is this expected behavior?  This seems to be caused by #require not
> >> expanding paths, so it requires spec_helper once per unique require
> >> statement (once per spec directory).
> >>
> >> It is resolved by wrapping the require at the top of each spec file
> >> with expand_path:
> >>
> >>   require File.expand_path(File.dirname(__FILE__) + '/../../
> >> spec_helper')
> >>
> >> It seems to me like this is something that require should do
> >> automatically.  Thoughts?
> >
> > Do you mean that Ruby's require should do the right thing, that rspec
> > should patch require to do the right thing, or that users should do
> > the right thing?
>
> Ideally I think Ruby's require should do the right thing, but that not
> being the case, I don't think rspec should change that behavior.  I
> guess rspec's generators should call expand_path, encouraging users to
> do the right thing.

Totally agree - would you kindly put in a feature request for that? Or
a patch even?

> I'll try to take this question farther upstream, but this issue
> primarily effects rspec and testunit in practice since they require
> the same file using different absolute paths, whereas other
> applications rely on the load path and relative paths.  Mainly I just
> wanted to bring it up to see if anyone had any insights as to why
> require works that way.

Ah - got it. That does seem to be a deficiency.

Cheers,
David

>
>
> Brandon
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From noreply at rubyforge.org  Tue Nov  6 11:32:14 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue,  6 Nov 2007 11:32:14 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-15394 ] RSpec website does
	not render correctly with IE6
Message-ID: <20071106163214.DC5FB1858598@rubyforge.org>

Feature Requests item #15394, was opened at 2007-11-06 16:32
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=15394&group_id=797

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: David Roberts (deejay)
Assigned to: Nobody (None)
Summary: RSpec website does not render correctly with IE6

Initial Comment:

RSpec website [ http://rspec.rubyforge.org/ ] does not render correctly with IE6 on WinXP - menu items run DOWN the page rather than across it, obscuring the upper part of the text on the page.

(Some may consider this should be a bug report against IE, but pragmatically I would just like potential users of RSpec on Windows to have a good experience and impression of RSpec.)


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=15394&group_id=797

From a.schur at nucleus.com  Tue Nov  6 13:39:45 2007
From: a.schur at nucleus.com (Alvin Schur)
Date: Tue, 06 Nov 2007 11:39:45 -0700
Subject: [rspec-devel] Stories vs. examples
In-Reply-To: <mailman.61.1194356612.30386.rspec-devel@rubyforge.org>
References: <mailman.61.1194356612.30386.rspec-devel@rubyforge.org>
Message-ID: <4730B4F1.40509@nucleus.com>

Are stories intended to mean "it worked in one case" to indicate a 
feature is present instead of being an exhaustive description of how 
edge cases are handled?

Are stories supposed to be comprehensive enough to pass a rigorous 
"heckling"?

Thanks,

Alvin.
> ------------------------------
>
> Message: 9
> Date: Tue, 6 Nov 2007 13:43:23 +0000
> From: "Dan North" <tastapod at gmail.com>
> Subject: Re: [rspec-devel] Stories vs. examples
> To: rspec-devel <rspec-devel at rubyforge.org>
> Message-ID:
> 	<d559d8430711060543g5d8954fbu157afcc177e847a1 at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi Ian.
>
> I find it helps to think about the audience for your documentation. (It is
> documentation after all, it just happens to run, which is rather nice.)
>
> For the specs, the audience is developers. They want to know what an object
> of a particular type - or more specifically in a particular role - does,
> which other objects it interacts with and why. This audience wants to see
> progress without leaving their IDE or editor, which is why we put effort
> into making TextMate plugins and why we want to play nice with all the
> Test::Unit runners.
>
> For the stories, the audience is testers, analysts and ultimately the
> various stakeholders who are requesting the features. They want to know what
> the system does and how to interact with it to get work done. They don't
> really care what happens under the hood. Typically they are non-technical
> (or less technical than developers) which is why we think there is so much
> value in making their documentation look like documentation - just plain
> words on a page. Even better, if you can give them green words on a page
> when the feature is implemented and working, or red words on a page when the
> feature isn't working, or grey words for unimplemented features, they can
> see progress in a living document. Now make that document editable, like a
> regular document, and you are well on your way to acceptance testing
> Nirvana.
>
> So the process (described as "outside in" as opposed to "top down" or
> "bottom up") starts by expressing a feature request as a story, driving out
> the scenarios that define "done" for that story and automating the steps
> that make up the scenarios. Then you use code-level examples to drive
> inwards (that word "drive" again) from the outermost objects that the steps
> identified. All the time you want to implement just enough behaviour to get
> the steps to work, to drive the scenarios. Then you're done and you go to
> the pub for a well-earned drink. Hence "beer-driven development".
>
> Hope that helps,
> Dan
>
> On 11/6/07, Ian Dees <undees at gmail.com> wrote:
>   
>> Hi, all.
>>
>> I'm posting a philosophical question here, rather than cluttering up
>> the tracker for the patch where it originated.
>>
>> Quoth David, in response to some fuzzy thinking on my part:
>>
>>     
>>> Stories are not just another way to express examples - they're a
>>>       
>> completely different animal.
>>
>> The offending clause of mine: "stories are another way to write your
>> tests.... examples are meant for small, targeted descriptions of your
>> code's behavior... stories are suited to longer, more detailed
>> narratives."
>>
>> The intent wasn't to say that stories are a different syntax for
>> examples; it was that stories and examples are two different syntaxes
>> for two different test-writing purposes.  But now I'm wondering if I
>> even have _that_ right.
>>
>> In Rails-land, the distinction is much clearer: you typically see
>> examples for testing code, and stories for testing applications (in
>> the blog posts I've read, anyway).
>>
>> But in GUI-land, the picture blurs a great deal: you're always testing
>> applications, but sometimes you're giving a tiny example of how one
>> feature works, and at other times you're writing a story about several
>> steps of an interaction between the customer and the UI.
>>
>> Anyone want to jump into these muddy waters?
>> _______________________________________________
>> rspec-devel mailing list
>> rspec-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>
>>     


From aslak.hellesoy at gmail.com  Tue Nov  6 16:13:42 2007
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Tue, 6 Nov 2007 22:13:42 +0100
Subject: [rspec-devel] Stories vs. examples
In-Reply-To: <4730B4F1.40509@nucleus.com>
References: <mailman.61.1194356612.30386.rspec-devel@rubyforge.org>
	<4730B4F1.40509@nucleus.com>
Message-ID: <8d961d900711061313y105d3694t85ddd51f8a5a1b9d@mail.gmail.com>

On Nov 6, 2007 7:39 PM, Alvin Schur <a.schur at nucleus.com> wrote:
> Are stories intended to mean "it worked in one case" to indicate a
> feature is present instead of being an exhaustive description of how
> edge cases are handled?
>

Stories is a way for domain experts (who don't necessarily know Ruby)
to express how they would like the software that doesn't exist to
behave.
For example, describing the business rules for whether someone should
be granted credit and how much based on age, gender, balance etc.
Or what should happen when you follow steps X, Y, Z in a business process.

It's a way to describe overall system behaviour with words without
even thinking about objects and classes (what domain experts care -
even know about -  those anyway)

> Are stories supposed to be comprehensive enough to pass a rigorous
> "heckling"?
>

Do you mean the heckle tool? It depends how much effort you want to
put into making your code bugfree. It's an interesting idea.

> Thanks,
>
> Alvin.
> > ------------------------------
> >
> > Message: 9
> > Date: Tue, 6 Nov 2007 13:43:23 +0000
> > From: "Dan North" <tastapod at gmail.com>
> > Subject: Re: [rspec-devel] Stories vs. examples
> > To: rspec-devel <rspec-devel at rubyforge.org>
> > Message-ID:
> >       <d559d8430711060543g5d8954fbu157afcc177e847a1 at mail.gmail.com>
> > Content-Type: text/plain; charset="iso-8859-1"
>
> >
> > Hi Ian.
> >
> > I find it helps to think about the audience for your documentation. (It is
> > documentation after all, it just happens to run, which is rather nice.)
> >
> > For the specs, the audience is developers. They want to know what an object
> > of a particular type - or more specifically in a particular role - does,
> > which other objects it interacts with and why. This audience wants to see
> > progress without leaving their IDE or editor, which is why we put effort
> > into making TextMate plugins and why we want to play nice with all the
> > Test::Unit runners.
> >
> > For the stories, the audience is testers, analysts and ultimately the
> > various stakeholders who are requesting the features. They want to know what
> > the system does and how to interact with it to get work done. They don't
> > really care what happens under the hood. Typically they are non-technical
> > (or less technical than developers) which is why we think there is so much
> > value in making their documentation look like documentation - just plain
> > words on a page. Even better, if you can give them green words on a page
> > when the feature is implemented and working, or red words on a page when the
> > feature isn't working, or grey words for unimplemented features, they can
> > see progress in a living document. Now make that document editable, like a
> > regular document, and you are well on your way to acceptance testing
> > Nirvana.
> >
> > So the process (described as "outside in" as opposed to "top down" or
> > "bottom up") starts by expressing a feature request as a story, driving out
> > the scenarios that define "done" for that story and automating the steps
> > that make up the scenarios. Then you use code-level examples to drive
> > inwards (that word "drive" again) from the outermost objects that the steps
> > identified. All the time you want to implement just enough behaviour to get
> > the steps to work, to drive the scenarios. Then you're done and you go to
> > the pub for a well-earned drink. Hence "beer-driven development".
> >
> > Hope that helps,
> > Dan
> >
> > On 11/6/07, Ian Dees <undees at gmail.com> wrote:
> >
> >> Hi, all.
> >>
> >> I'm posting a philosophical question here, rather than cluttering up
> >> the tracker for the patch where it originated.
> >>
> >> Quoth David, in response to some fuzzy thinking on my part:
> >>
> >>
> >>> Stories are not just another way to express examples - they're a
> >>>
> >> completely different animal.
> >>
> >> The offending clause of mine: "stories are another way to write your
> >> tests.... examples are meant for small, targeted descriptions of your
> >> code's behavior... stories are suited to longer, more detailed
> >> narratives."
> >>
> >> The intent wasn't to say that stories are a different syntax for
> >> examples; it was that stories and examples are two different syntaxes
> >> for two different test-writing purposes.  But now I'm wondering if I
> >> even have _that_ right.
> >>
> >> In Rails-land, the distinction is much clearer: you typically see
> >> examples for testing code, and stories for testing applications (in
> >> the blog posts I've read, anyway).
> >>
> >> But in GUI-land, the picture blurs a great deal: you're always testing
> >> applications, but sometimes you're giving a tiny example of how one
> >> feature works, and at other times you're writing a story about several
> >> steps of an interaction between the customer and the UI.
> >>
> >> Anyone want to jump into these muddy waters?
> >> _______________________________________________
> >> rspec-devel mailing list
> >> rspec-devel at rubyforge.org
> >> http://rubyforge.org/mailman/listinfo/rspec-devel
> >>
> >>
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From aslak.hellesoy at gmail.com  Tue Nov  6 16:25:27 2007
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Tue, 6 Nov 2007 22:25:27 +0100
Subject: [rspec-devel] Stories vs. examples
In-Reply-To: <4730B4F1.40509@nucleus.com>
References: <mailman.61.1194356612.30386.rspec-devel@rubyforge.org>
	<4730B4F1.40509@nucleus.com>
Message-ID: <8d961d900711061325g36a2eea6l4e754baa00b6594f@mail.gmail.com>

On Nov 6, 2007 7:39 PM, Alvin Schur <a.schur at nucleus.com> wrote:
> Are stories intended to mean "it worked in one case" to indicate a
> feature is present instead of being an exhaustive description of how
> edge cases are handled?
>

Ideally, yes. You'll typically have one scenario for each edge case. A
story has many scenarios (which again have many steps - G/W/T)

Aslak

> Are stories supposed to be comprehensive enough to pass a rigorous
> "heckling"?
>
> Thanks,
>
> Alvin.
> > ------------------------------
> >
> > Message: 9
> > Date: Tue, 6 Nov 2007 13:43:23 +0000
> > From: "Dan North" <tastapod at gmail.com>
> > Subject: Re: [rspec-devel] Stories vs. examples
> > To: rspec-devel <rspec-devel at rubyforge.org>
> > Message-ID:
> >       <d559d8430711060543g5d8954fbu157afcc177e847a1 at mail.gmail.com>
> > Content-Type: text/plain; charset="iso-8859-1"
>
> >
> > Hi Ian.
> >
> > I find it helps to think about the audience for your documentation. (It is
> > documentation after all, it just happens to run, which is rather nice.)
> >
> > For the specs, the audience is developers. They want to know what an object
> > of a particular type - or more specifically in a particular role - does,
> > which other objects it interacts with and why. This audience wants to see
> > progress without leaving their IDE or editor, which is why we put effort
> > into making TextMate plugins and why we want to play nice with all the
> > Test::Unit runners.
> >
> > For the stories, the audience is testers, analysts and ultimately the
> > various stakeholders who are requesting the features. They want to know what
> > the system does and how to interact with it to get work done. They don't
> > really care what happens under the hood. Typically they are non-technical
> > (or less technical than developers) which is why we think there is so much
> > value in making their documentation look like documentation - just plain
> > words on a page. Even better, if you can give them green words on a page
> > when the feature is implemented and working, or red words on a page when the
> > feature isn't working, or grey words for unimplemented features, they can
> > see progress in a living document. Now make that document editable, like a
> > regular document, and you are well on your way to acceptance testing
> > Nirvana.
> >
> > So the process (described as "outside in" as opposed to "top down" or
> > "bottom up") starts by expressing a feature request as a story, driving out
> > the scenarios that define "done" for that story and automating the steps
> > that make up the scenarios. Then you use code-level examples to drive
> > inwards (that word "drive" again) from the outermost objects that the steps
> > identified. All the time you want to implement just enough behaviour to get
> > the steps to work, to drive the scenarios. Then you're done and you go to
> > the pub for a well-earned drink. Hence "beer-driven development".
> >
> > Hope that helps,
> > Dan
> >
> > On 11/6/07, Ian Dees <undees at gmail.com> wrote:
> >
> >> Hi, all.
> >>
> >> I'm posting a philosophical question here, rather than cluttering up
> >> the tracker for the patch where it originated.
> >>
> >> Quoth David, in response to some fuzzy thinking on my part:
> >>
> >>
> >>> Stories are not just another way to express examples - they're a
> >>>
> >> completely different animal.
> >>
> >> The offending clause of mine: "stories are another way to write your
> >> tests.... examples are meant for small, targeted descriptions of your
> >> code's behavior... stories are suited to longer, more detailed
> >> narratives."
> >>
> >> The intent wasn't to say that stories are a different syntax for
> >> examples; it was that stories and examples are two different syntaxes
> >> for two different test-writing purposes.  But now I'm wondering if I
> >> even have _that_ right.
> >>
> >> In Rails-land, the distinction is much clearer: you typically see
> >> examples for testing code, and stories for testing applications (in
> >> the blog posts I've read, anyway).
> >>
> >> But in GUI-land, the picture blurs a great deal: you're always testing
> >> applications, but sometimes you're giving a tiny example of how one
> >> feature works, and at other times you're writing a story about several
> >> steps of an interaction between the customer and the UI.
> >>
> >> Anyone want to jump into these muddy waters?
> >> _______________________________________________
> >> rspec-devel mailing list
> >> rspec-devel at rubyforge.org
> >> http://rubyforge.org/mailman/listinfo/rspec-devel
> >>
> >>
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From jake.howerton at gmail.com  Tue Nov  6 16:34:39 2007
From: jake.howerton at gmail.com (Jake Howerton)
Date: Tue, 6 Nov 2007 16:34:39 -0500
Subject: [rspec-devel] Stories vs. examples
In-Reply-To: <8d961d900711061325g36a2eea6l4e754baa00b6594f@mail.gmail.com>
References: <mailman.61.1194356612.30386.rspec-devel@rubyforge.org>
	<4730B4F1.40509@nucleus.com>
	<8d961d900711061325g36a2eea6l4e754baa00b6594f@mail.gmail.com>
Message-ID: <218a05e40711061334h5b21a3b8l3c1f2c29e78ed9e6@mail.gmail.com>

This makes me wonder if some sort of bug tracking system could be
integrated into the browser story editor where testers/customers could
enter the passing and failing story.

Bug Scenario: bad addition to cart
 Given user has two apples in cart

 When user adds two apples to cart

 Then user has three apples in cart

Expected Scenario: proper addition to cart
 Given user has two apples in cart

 When user adds two apples to cart

 Then user has four apples in cart

When you fix the bug you can promote the expected scenario to a first
class scenario ( or merge it with the one that did not cover the bug
properly),  and store the bug regression stories somewhere to ensure
they do not fail in the future.

WDYT?

Jake

On Nov 6, 2007 4:25 PM, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> On Nov 6, 2007 7:39 PM, Alvin Schur <a.schur at nucleus.com> wrote:
> > Are stories intended to mean "it worked in one case" to indicate a
> > feature is present instead of being an exhaustive description of how
> > edge cases are handled?
> >
>
> Ideally, yes. You'll typically have one scenario for each edge case. A
> story has many scenarios (which again have many steps - G/W/T)
>
> Aslak
>
> > Are stories supposed to be comprehensive enough to pass a rigorous
> > "heckling"?
> >
> > Thanks,
> >
> > Alvin.
> > > ------------------------------
> > >
> > > Message: 9
> > > Date: Tue, 6 Nov 2007 13:43:23 +0000
> > > From: "Dan North" <tastapod at gmail.com>
> > > Subject: Re: [rspec-devel] Stories vs. examples
> > > To: rspec-devel <rspec-devel at rubyforge.org>
> > > Message-ID:
> > >       <d559d8430711060543g5d8954fbu157afcc177e847a1 at mail.gmail.com>
> > > Content-Type: text/plain; charset="iso-8859-1"
> >
> > >
> > > Hi Ian.
> > >
> > > I find it helps to think about the audience for your documentation. (It is
> > > documentation after all, it just happens to run, which is rather nice.)
> > >
> > > For the specs, the audience is developers. They want to know what an object
> > > of a particular type - or more specifically in a particular role - does,
> > > which other objects it interacts with and why. This audience wants to see
> > > progress without leaving their IDE or editor, which is why we put effort
> > > into making TextMate plugins and why we want to play nice with all the
> > > Test::Unit runners.
> > >
> > > For the stories, the audience is testers, analysts and ultimately the
> > > various stakeholders who are requesting the features. They want to know what
> > > the system does and how to interact with it to get work done. They don't
> > > really care what happens under the hood. Typically they are non-technical
> > > (or less technical than developers) which is why we think there is so much
> > > value in making their documentation look like documentation - just plain
> > > words on a page. Even better, if you can give them green words on a page
> > > when the feature is implemented and working, or red words on a page when the
> > > feature isn't working, or grey words for unimplemented features, they can
> > > see progress in a living document. Now make that document editable, like a
> > > regular document, and you are well on your way to acceptance testing
> > > Nirvana.
> > >
> > > So the process (described as "outside in" as opposed to "top down" or
> > > "bottom up") starts by expressing a feature request as a story, driving out
> > > the scenarios that define "done" for that story and automating the steps
> > > that make up the scenarios. Then you use code-level examples to drive
> > > inwards (that word "drive" again) from the outermost objects that the steps
> > > identified. All the time you want to implement just enough behaviour to get
> > > the steps to work, to drive the scenarios. Then you're done and you go to
> > > the pub for a well-earned drink. Hence "beer-driven development".
> > >
> > > Hope that helps,
> > > Dan
> > >
> > > On 11/6/07, Ian Dees <undees at gmail.com> wrote:
> > >
> > >> Hi, all.
> > >>
> > >> I'm posting a philosophical question here, rather than cluttering up
> > >> the tracker for the patch where it originated.
> > >>
> > >> Quoth David, in response to some fuzzy thinking on my part:
> > >>
> > >>
> > >>> Stories are not just another way to express examples - they're a
> > >>>
> > >> completely different animal.
> > >>
> > >> The offending clause of mine: "stories are another way to write your
> > >> tests.... examples are meant for small, targeted descriptions of your
> > >> code's behavior... stories are suited to longer, more detailed
> > >> narratives."
> > >>
> > >> The intent wasn't to say that stories are a different syntax for
> > >> examples; it was that stories and examples are two different syntaxes
> > >> for two different test-writing purposes.  But now I'm wondering if I
> > >> even have _that_ right.
> > >>
> > >> In Rails-land, the distinction is much clearer: you typically see
> > >> examples for testing code, and stories for testing applications (in
> > >> the blog posts I've read, anyway).
> > >>
> > >> But in GUI-land, the picture blurs a great deal: you're always testing
> > >> applications, but sometimes you're giving a tiny example of how one
> > >> feature works, and at other times you're writing a story about several
> > >> steps of an interaction between the customer and the UI.
> > >>
> > >> Anyone want to jump into these muddy waters?
> > >> _______________________________________________
> > >> rspec-devel mailing list
> > >> rspec-devel at rubyforge.org
> > >> http://rubyforge.org/mailman/listinfo/rspec-devel
> > >>
> > >>
> >
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From dchelimsky at gmail.com  Tue Nov  6 16:36:51 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 6 Nov 2007 15:36:51 -0600
Subject: [rspec-devel] Stories vs. examples
In-Reply-To: <218a05e40711061334h5b21a3b8l3c1f2c29e78ed9e6@mail.gmail.com>
References: <mailman.61.1194356612.30386.rspec-devel@rubyforge.org>
	<4730B4F1.40509@nucleus.com>
	<8d961d900711061325g36a2eea6l4e754baa00b6594f@mail.gmail.com>
	<218a05e40711061334h5b21a3b8l3c1f2c29e78ed9e6@mail.gmail.com>
Message-ID: <57c63afe0711061336x513f07c9x1120791c667d268a@mail.gmail.com>

On Nov 6, 2007 3:34 PM, Jake Howerton <jake.howerton at gmail.com> wrote:
> This makes me wonder if some sort of bug tracking system could be
> integrated into the browser story editor where testers/customers could
> enter the passing and failing story.
>
> Bug Scenario: bad addition to cart
>  Given user has two apples in cart
>
>  When user adds two apples to cart
>
>  Then user has three apples in cart
>
> Expected Scenario: proper addition to cart
>  Given user has two apples in cart
>
>  When user adds two apples to cart
>
>  Then user has four apples in cart
>
> When you fix the bug you can promote the expected scenario to a first
> class scenario ( or merge it with the one that did not cover the bug
> properly),  and store the bug regression stories somewhere to ensure
> they do not fail in the future.
>
> WDYT?

I think that's a short bit down the road, but definitely feasible and useful.

Cheers,
David

From tastapod at gmail.com  Tue Nov  6 17:12:53 2007
From: tastapod at gmail.com (Dan North)
Date: Tue, 6 Nov 2007 22:12:53 +0000
Subject: [rspec-devel] Stories vs. examples
In-Reply-To: <218a05e40711061334h5b21a3b8l3c1f2c29e78ed9e6@mail.gmail.com>
References: <mailman.61.1194356612.30386.rspec-devel@rubyforge.org>
	<4730B4F1.40509@nucleus.com>
	<8d961d900711061325g36a2eea6l4e754baa00b6594f@mail.gmail.com>
	<218a05e40711061334h5b21a3b8l3c1f2c29e78ed9e6@mail.gmail.com>
Message-ID: <d559d8430711061412qce8272ev7f4f749bb5bc7044@mail.gmail.com>

Hi Jake.

This is already happening on real projects (albeit Java and .Net ones using
things like Selenium to automate the scenarios). On most projects in
ThoughtWorks, when a tester finds a defect they describe it in terms of a
(failing) scenario. What it means is that the original story was missing an
edge case - or there was an invalid assumption - that has been flushed out
by testing.

Sometimes they use the defect number from the tracking system in the
scenario name. On one recent project the team didn't even have a separate
process for tracking bugs. A defect just came into the next iteration's
planning session as a failing scenario (described on a card rather than
automated at this stage) and got played into the workstream like any other
piece of work. The team found they actually had less to do because they
didn't have the overhead of managing a separate defect-tracking process.


On 11/6/07, Jake Howerton <jake.howerton at gmail.com> wrote:
>
> This makes me wonder if some sort of bug tracking system could be
> integrated into the browser story editor where testers/customers could
> enter the passing and failing story.
>
> Bug Scenario: bad addition to cart
> Given user has two apples in cart
>
> When user adds two apples to cart
>
> Then user has three apples in cart
>
> Expected Scenario: proper addition to cart
> Given user has two apples in cart
>
> When user adds two apples to cart
>
> Then user has four apples in cart
>
> When you fix the bug you can promote the expected scenario to a first
> class scenario ( or merge it with the one that did not cover the bug
> properly),  and store the bug regression stories somewhere to ensure
> they do not fail in the future.
>
> WDYT?
>
> Jake
>
> On Nov 6, 2007 4:25 PM, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > On Nov 6, 2007 7:39 PM, Alvin Schur <a.schur at nucleus.com> wrote:
> > > Are stories intended to mean "it worked in one case" to indicate a
> > > feature is present instead of being an exhaustive description of how
> > > edge cases are handled?
> > >
> >
> > Ideally, yes. You'll typically have one scenario for each edge case. A
> > story has many scenarios (which again have many steps - G/W/T)
> >
> > Aslak
> >
> > > Are stories supposed to be comprehensive enough to pass a rigorous
> > > "heckling"?
> > >
> > > Thanks,
> > >
> > > Alvin.
> > > > ------------------------------
> > > >
> > > > Message: 9
> > > > Date: Tue, 6 Nov 2007 13:43:23 +0000
> > > > From: "Dan North" <tastapod at gmail.com>
> > > > Subject: Re: [rspec-devel] Stories vs. examples
> > > > To: rspec-devel <rspec-devel at rubyforge.org>
> > > > Message-ID:
> > > >       <d559d8430711060543g5d8954fbu157afcc177e847a1 at mail.gmail.com>
> > > > Content-Type: text/plain; charset="iso-8859-1"
> > >
> > > >
> > > > Hi Ian.
> > > >
> > > > I find it helps to think about the audience for your documentation.
> (It is
> > > > documentation after all, it just happens to run, which is rather
> nice.)
> > > >
> > > > For the specs, the audience is developers. They want to know what an
> object
> > > > of a particular type - or more specifically in a particular role -
> does,
> > > > which other objects it interacts with and why. This audience wants
> to see
> > > > progress without leaving their IDE or editor, which is why we put
> effort
> > > > into making TextMate plugins and why we want to play nice with all
> the
> > > > Test::Unit runners.
> > > >
> > > > For the stories, the audience is testers, analysts and ultimately
> the
> > > > various stakeholders who are requesting the features. They want to
> know what
> > > > the system does and how to interact with it to get work done. They
> don't
> > > > really care what happens under the hood. Typically they are
> non-technical
> > > > (or less technical than developers) which is why we think there is
> so much
> > > > value in making their documentation look like documentation - just
> plain
> > > > words on a page. Even better, if you can give them green words on a
> page
> > > > when the feature is implemented and working, or red words on a page
> when the
> > > > feature isn't working, or grey words for unimplemented features,
> they can
> > > > see progress in a living document. Now make that document editable,
> like a
> > > > regular document, and you are well on your way to acceptance testing
> > > > Nirvana.
> > > >
> > > > So the process (described as "outside in" as opposed to "top down"
> or
> > > > "bottom up") starts by expressing a feature request as a story,
> driving out
> > > > the scenarios that define "done" for that story and automating the
> steps
> > > > that make up the scenarios. Then you use code-level examples to
> drive
> > > > inwards (that word "drive" again) from the outermost objects that
> the steps
> > > > identified. All the time you want to implement just enough behaviour
> to get
> > > > the steps to work, to drive the scenarios. Then you're done and you
> go to
> > > > the pub for a well-earned drink. Hence "beer-driven development".
> > > >
> > > > Hope that helps,
> > > > Dan
> > > >
> > > > On 11/6/07, Ian Dees <undees at gmail.com> wrote:
> > > >
> > > >> Hi, all.
> > > >>
> > > >> I'm posting a philosophical question here, rather than cluttering
> up
> > > >> the tracker for the patch where it originated.
> > > >>
> > > >> Quoth David, in response to some fuzzy thinking on my part:
> > > >>
> > > >>
> > > >>> Stories are not just another way to express examples - they're a
> > > >>>
> > > >> completely different animal.
> > > >>
> > > >> The offending clause of mine: "stories are another way to write
> your
> > > >> tests.... examples are meant for small, targeted descriptions of
> your
> > > >> code's behavior... stories are suited to longer, more detailed
> > > >> narratives."
> > > >>
> > > >> The intent wasn't to say that stories are a different syntax for
> > > >> examples; it was that stories and examples are two different
> syntaxes
> > > >> for two different test-writing purposes.  But now I'm wondering if
> I
> > > >> even have _that_ right.
> > > >>
> > > >> In Rails-land, the distinction is much clearer: you typically see
> > > >> examples for testing code, and stories for testing applications (in
> > > >> the blog posts I've read, anyway).
> > > >>
> > > >> But in GUI-land, the picture blurs a great deal: you're always
> testing
> > > >> applications, but sometimes you're giving a tiny example of how one
> > > >> feature works, and at other times you're writing a story about
> several
> > > >> steps of an interaction between the customer and the UI.
> > > >>
> > > >> Anyone want to jump into these muddy waters?
> > > >> _______________________________________________
> > > >> rspec-devel mailing list
> > > >> rspec-devel at rubyforge.org
> > > >> http://rubyforge.org/mailman/listinfo/rspec-devel
> > > >>
> > > >>
> > >
> > > _______________________________________________
> > > rspec-devel mailing list
> > > rspec-devel at rubyforge.org
> > > http://rubyforge.org/mailman/listinfo/rspec-devel
> > >
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20071106/d0ea50d5/attachment-0001.html 

From mlangenberg at gmail.com  Wed Nov  7 03:04:56 2007
From: mlangenberg at gmail.com (Matthijs Langenberg)
Date: Wed, 7 Nov 2007 09:04:56 +0100
Subject: [rspec-devel] Stories vs. examples
In-Reply-To: <218a05e40711061334h5b21a3b8l3c1f2c29e78ed9e6@mail.gmail.com>
References: <mailman.61.1194356612.30386.rspec-devel@rubyforge.org>
	<4730B4F1.40509@nucleus.com>
	<8d961d900711061325g36a2eea6l4e754baa00b6594f@mail.gmail.com>
	<218a05e40711061334h5b21a3b8l3c1f2c29e78ed9e6@mail.gmail.com>
Message-ID: <27c0ac6d0711070004q3b5989ddy7d4b4af0e0770339@mail.gmail.com>

Would this also mean that the guy writing the story is defining the
functional part of the GUI?Since it's the most outer layer of the system,
would that be described in a story first?
Like: "Given a user and a form with a button, when a user clicks the button,
then the world should come to an end."

(I'm waiting for a book to come out, describing all this very cool stuff.)

On Nov 6, 2007 10:34 PM, Jake Howerton <jake.howerton at gmail.com> wrote:

> This makes me wonder if some sort of bug tracking system could be
> integrated into the browser story editor where testers/customers could
> enter the passing and failing story.
>
> Bug Scenario: bad addition to cart
>  Given user has two apples in cart
>
>  When user adds two apples to cart
>
>  Then user has three apples in cart
>
> Expected Scenario: proper addition to cart
>  Given user has two apples in cart
>
>  When user adds two apples to cart
>
>  Then user has four apples in cart
>
> When you fix the bug you can promote the expected scenario to a first
> class scenario ( or merge it with the one that did not cover the bug
> properly),  and store the bug regression stories somewhere to ensure
> they do not fail in the future.
>
> WDYT?
>
> Jake
>
> On Nov 6, 2007 4:25 PM, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > On Nov 6, 2007 7:39 PM, Alvin Schur <a.schur at nucleus.com> wrote:
> > > Are stories intended to mean "it worked in one case" to indicate a
> > > feature is present instead of being an exhaustive description of how
> > > edge cases are handled?
> > >
> >
> > Ideally, yes. You'll typically have one scenario for each edge case. A
> > story has many scenarios (which again have many steps - G/W/T)
> >
> > Aslak
> >
> > > Are stories supposed to be comprehensive enough to pass a rigorous
> > > "heckling"?
> > >
> > > Thanks,
> > >
> > > Alvin.
> > > > ------------------------------
> > > >
> > > > Message: 9
> > > > Date: Tue, 6 Nov 2007 13:43:23 +0000
> > > > From: "Dan North" <tastapod at gmail.com>
> > > > Subject: Re: [rspec-devel] Stories vs. examples
> > > > To: rspec-devel <rspec-devel at rubyforge.org>
> > > > Message-ID:
> > > >       <d559d8430711060543g5d8954fbu157afcc177e847a1 at mail.gmail.com>
> > > > Content-Type: text/plain; charset="iso-8859-1"
> > >
> > > >
> > > > Hi Ian.
> > > >
> > > > I find it helps to think about the audience for your documentation.
> (It is
> > > > documentation after all, it just happens to run, which is rather
> nice.)
> > > >
> > > > For the specs, the audience is developers. They want to know what an
> object
> > > > of a particular type - or more specifically in a particular role -
> does,
> > > > which other objects it interacts with and why. This audience wants
> to see
> > > > progress without leaving their IDE or editor, which is why we put
> effort
> > > > into making TextMate plugins and why we want to play nice with all
> the
> > > > Test::Unit runners.
> > > >
> > > > For the stories, the audience is testers, analysts and ultimately
> the
> > > > various stakeholders who are requesting the features. They want to
> know what
> > > > the system does and how to interact with it to get work done. They
> don't
> > > > really care what happens under the hood. Typically they are
> non-technical
> > > > (or less technical than developers) which is why we think there is
> so much
> > > > value in making their documentation look like documentation - just
> plain
> > > > words on a page. Even better, if you can give them green words on a
> page
> > > > when the feature is implemented and working, or red words on a page
> when the
> > > > feature isn't working, or grey words for unimplemented features,
> they can
> > > > see progress in a living document. Now make that document editable,
> like a
> > > > regular document, and you are well on your way to acceptance testing
> > > > Nirvana.
> > > >
> > > > So the process (described as "outside in" as opposed to "top down"
> or
> > > > "bottom up") starts by expressing a feature request as a story,
> driving out
> > > > the scenarios that define "done" for that story and automating the
> steps
> > > > that make up the scenarios. Then you use code-level examples to
> drive
> > > > inwards (that word "drive" again) from the outermost objects that
> the steps
> > > > identified. All the time you want to implement just enough behaviour
> to get
> > > > the steps to work, to drive the scenarios. Then you're done and you
> go to
> > > > the pub for a well-earned drink. Hence "beer-driven development".
> > > >
> > > > Hope that helps,
> > > > Dan
> > > >
> > > > On 11/6/07, Ian Dees <undees at gmail.com> wrote:
> > > >
> > > >> Hi, all.
> > > >>
> > > >> I'm posting a philosophical question here, rather than cluttering
> up
> > > >> the tracker for the patch where it originated.
> > > >>
> > > >> Quoth David, in response to some fuzzy thinking on my part:
> > > >>
> > > >>
> > > >>> Stories are not just another way to express examples - they're a
> > > >>>
> > > >> completely different animal.
> > > >>
> > > >> The offending clause of mine: "stories are another way to write
> your
> > > >> tests.... examples are meant for small, targeted descriptions of
> your
> > > >> code's behavior... stories are suited to longer, more detailed
> > > >> narratives."
> > > >>
> > > >> The intent wasn't to say that stories are a different syntax for
> > > >> examples; it was that stories and examples are two different
> syntaxes
> > > >> for two different test-writing purposes.  But now I'm wondering if
> I
> > > >> even have _that_ right.
> > > >>
> > > >> In Rails-land, the distinction is much clearer: you typically see
> > > >> examples for testing code, and stories for testing applications (in
> > > >> the blog posts I've read, anyway).
> > > >>
> > > >> But in GUI-land, the picture blurs a great deal: you're always
> testing
> > > >> applications, but sometimes you're giving a tiny example of how one
> > > >> feature works, and at other times you're writing a story about
> several
> > > >> steps of an interaction between the customer and the UI.
> > > >>
> > > >> Anyone want to jump into these muddy waters?
> > > >> _______________________________________________
> > > >> rspec-devel mailing list
> > > >> rspec-devel at rubyforge.org
> > > >> http://rubyforge.org/mailman/listinfo/rspec-devel
> > > >>
> > > >>
> > >
> > > _______________________________________________
> > > rspec-devel mailing list
> > > rspec-devel at rubyforge.org
> > > http://rubyforge.org/mailman/listinfo/rspec-devel
> > >
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20071107/1f5c1994/attachment.html 

From dchelimsky at gmail.com  Wed Nov  7 09:15:25 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 7 Nov 2007 08:15:25 -0600
Subject: [rspec-devel] Stories vs. examples
In-Reply-To: <27c0ac6d0711070004q3b5989ddy7d4b4af0e0770339@mail.gmail.com>
References: <mailman.61.1194356612.30386.rspec-devel@rubyforge.org>
	<4730B4F1.40509@nucleus.com>
	<8d961d900711061325g36a2eea6l4e754baa00b6594f@mail.gmail.com>
	<218a05e40711061334h5b21a3b8l3c1f2c29e78ed9e6@mail.gmail.com>
	<27c0ac6d0711070004q3b5989ddy7d4b4af0e0770339@mail.gmail.com>
Message-ID: <57c63afe0711070615p7d54aa2pfea3d287b3e814b4@mail.gmail.com>

On Nov 7, 2007 2:04 AM, Matthijs Langenberg <mlangenberg at gmail.com> wrote:
> Would this also mean that the guy writing the story is defining the
> functional part of the GUI?
> Since it's the most outer layer of the system, would that be described in a
> story first?
> Like: "Given a user and a form with a button, when a user clicks the button,
> then the world should come to an end."

There should likely be both interaction stories like that AND business
rule stories, like the one Dan uses in
http://dannorth.net/2007/06/introducing-rbehave. If every story takes
you through every step, they all become too big IMO.

From tastapod at gmail.com  Wed Nov  7 10:28:52 2007
From: tastapod at gmail.com (Dan North)
Date: Wed, 7 Nov 2007 15:28:52 +0000
Subject: [rspec-devel] Stories vs. examples
In-Reply-To: <57c63afe0711070615p7d54aa2pfea3d287b3e814b4@mail.gmail.com>
References: <mailman.61.1194356612.30386.rspec-devel@rubyforge.org>
	<4730B4F1.40509@nucleus.com>
	<8d961d900711061325g36a2eea6l4e754baa00b6594f@mail.gmail.com>
	<218a05e40711061334h5b21a3b8l3c1f2c29e78ed9e6@mail.gmail.com>
	<27c0ac6d0711070004q3b5989ddy7d4b4af0e0770339@mail.gmail.com>
	<57c63afe0711070615p7d54aa2pfea3d287b3e814b4@mail.gmail.com>
Message-ID: <d559d8430711070728l1fcc1432hb4779c5abbc769d@mail.gmail.com>

Exactly. The behaviour description works in conjunction with other material
that help with the non-behavioural aspects, like screen layouts or design
guidelines. You would probably have a lo-fi mock-up of the login screen
(just a drawing) with the User and Password fields and Login button
labelled. Then the story would refer to those elements.


On 11/7/07, David Chelimsky <dchelimsky at gmail.com> wrote:
>
> On Nov 7, 2007 2:04 AM, Matthijs Langenberg <mlangenberg at gmail.com> wrote:
> > Would this also mean that the guy writing the story is defining the
> > functional part of the GUI?
> > Since it's the most outer layer of the system, would that be described
> in a
> > story first?
> > Like: "Given a user and a form with a button, when a user clicks the
> button,
> > then the world should come to an end."
>
> There should likely be both interaction stories like that AND business
> rule stories, like the one Dan uses in
> http://dannorth.net/2007/06/introducing-rbehave. If every story takes
> you through every step, they all become too big IMO.
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20071107/bbb8cbc8/attachment.html 

From ddeaguiar at archcreekconsulting.com  Wed Nov  7 12:08:32 2007
From: ddeaguiar at archcreekconsulting.com (Daniel De Aguiar)
Date: Wed, 7 Nov 2007 12:08:32 -0500
Subject: [rspec-devel] Stories vs. examples
In-Reply-To: <d559d8430711070728l1fcc1432hb4779c5abbc769d@mail.gmail.com>
References: <mailman.61.1194356612.30386.rspec-devel@rubyforge.org>
	<4730B4F1.40509@nucleus.com>
	<8d961d900711061325g36a2eea6l4e754baa00b6594f@mail.gmail.com>
	<218a05e40711061334h5b21a3b8l3c1f2c29e78ed9e6@mail.gmail.com>
	<27c0ac6d0711070004q3b5989ddy7d4b4af0e0770339@mail.gmail.com>
	<57c63afe0711070615p7d54aa2pfea3d287b3e814b4@mail.gmail.com>
	<d559d8430711070728l1fcc1432hb4779c5abbc769d@mail.gmail.com>
Message-ID: <098A529F-2023-4411-8E36-9F9A9D5ED2A1@archcreekconsulting.com>

Stories should be technology agnostic. I don't think form references,  
for example, have a place in them.

I think technology-specific interaction story information is best  
captured in a different way, particularly in a "non-executable" format.

- Dan

On Nov 7, 2007, at 10:28 AM, "Dan North" <tastapod at gmail.com> wrote:

> Exactly. The behaviour description works in conjunction with other  
> material that help with the non-behavioural aspects, like screen  
> layouts or design guidelines. You would probably have a lo-fi mock- 
> up of the login screen (just a drawing) with the User and Password  
> fields and Login button labelled. Then the story would refer to  
> those elements.
>
>
> On 11/7/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> On Nov 7, 2007 2:04 AM, Matthijs Langenberg <mlangenberg at gmail.com>  
> wrote:
> > Would this also mean that the guy writing the story is defining the
> > functional part of the GUI?
> > Since it's the most outer layer of the system, would that be  
> described in a
> > story first?
> > Like: "Given a user and a form with a button, when a user clicks  
> the button,
> > then the world should come to an end."
>
> There should likely be both interaction stories like that AND business
> rule stories, like the one Dan uses in
> http://dannorth.net/2007/06/introducing-rbehave . If every story takes
> you through every step, they all become too big IMO.
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20071107/c76aff93/attachment-0001.html 

From jake.howerton at gmail.com  Wed Nov  7 12:31:13 2007
From: jake.howerton at gmail.com (Jake Howerton)
Date: Wed, 7 Nov 2007 12:31:13 -0500
Subject: [rspec-devel] Stories vs. examples
In-Reply-To: <098A529F-2023-4411-8E36-9F9A9D5ED2A1@archcreekconsulting.com>
References: <mailman.61.1194356612.30386.rspec-devel@rubyforge.org>
	<4730B4F1.40509@nucleus.com>
	<8d961d900711061325g36a2eea6l4e754baa00b6594f@mail.gmail.com>
	<218a05e40711061334h5b21a3b8l3c1f2c29e78ed9e6@mail.gmail.com>
	<27c0ac6d0711070004q3b5989ddy7d4b4af0e0770339@mail.gmail.com>
	<57c63afe0711070615p7d54aa2pfea3d287b3e814b4@mail.gmail.com>
	<d559d8430711070728l1fcc1432hb4779c5abbc769d@mail.gmail.com>
	<098A529F-2023-4411-8E36-9F9A9D5ED2A1@archcreekconsulting.com>
Message-ID: <218a05e40711070931h665b12e5m23cb918989e86d6c@mail.gmail.com>

Dan,

I am not sure about that, when I am looking at writing a story for a
web app, if I try and abstract the browser out of it, it stops making
sense.

You need to be sufficiently close to the metal to drive the implementation.

Scenario: get index
		Given user is authenticated as admin
		And user is at manage library page
		
		When user clicks Manage Local Partners link
		
		Then user is brought to partners index

Here is an example from an app I am working on.  The language 'clicks'
and 'link' expressly imply that I am using a browser interface.
I can definitely swap out the step implementation for safariwatir vs
rails integration tests still.   How would you write a story like
this?

Jake

On Nov 7, 2007 12:08 PM, Daniel De Aguiar
<ddeaguiar at archcreekconsulting.com> wrote:
>
> Stories should be technology agnostic. I don't think form references, for
> example, have a place in them.
>
> I think technology-specific interaction story information is best captured
> in a different way, particularly in a "non-executable" format.
>
> - Dan
>
> On Nov 7, 2007, at 10:28 AM, "Dan North" <tastapod at gmail.com> wrote:
>
>
> Exactly. The behaviour description works in conjunction with other material
> that help with the non-behavioural aspects, like screen layouts or design
> guidelines. You would probably have a lo-fi mock-up of the login screen
> (just a drawing) with the User and Password fields and Login button
> labelled. Then the story would refer to those elements.
>
>
> On 11/7/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> > On Nov 7, 2007 2:04 AM, Matthijs Langenberg <mlangenberg at gmail.com> wrote:
> > > Would this also mean that the guy writing the story is defining the
> > > functional part of the GUI?
> > > Since it's the most outer layer of the system, would that be described
> in a
> > > story first?
> > > Like: "Given a user and a form with a button, when a user clicks the
> button,
> > > then the world should come to an end."
> >
> > There should likely be both interaction stories like that AND business
> > rule stories, like the one Dan uses in
> > http://dannorth.net/2007/06/introducing-rbehave . If every story takes
> > you through every step, they all become too big IMO.
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
>
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From dchelimsky at gmail.com  Wed Nov  7 12:35:34 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 7 Nov 2007 11:35:34 -0600
Subject: [rspec-devel] Stories vs. examples
In-Reply-To: <218a05e40711070931h665b12e5m23cb918989e86d6c@mail.gmail.com>
References: <mailman.61.1194356612.30386.rspec-devel@rubyforge.org>
	<4730B4F1.40509@nucleus.com>
	<8d961d900711061325g36a2eea6l4e754baa00b6594f@mail.gmail.com>
	<218a05e40711061334h5b21a3b8l3c1f2c29e78ed9e6@mail.gmail.com>
	<27c0ac6d0711070004q3b5989ddy7d4b4af0e0770339@mail.gmail.com>
	<57c63afe0711070615p7d54aa2pfea3d287b3e814b4@mail.gmail.com>
	<d559d8430711070728l1fcc1432hb4779c5abbc769d@mail.gmail.com>
	<098A529F-2023-4411-8E36-9F9A9D5ED2A1@archcreekconsulting.com>
	<218a05e40711070931h665b12e5m23cb918989e86d6c@mail.gmail.com>
Message-ID: <57c63afe0711070935q150dd638hb76847b1a9c34146@mail.gmail.com>

On Nov 7, 2007 11:31 AM, Jake Howerton <jake.howerton at gmail.com> wrote:
> Dan,
>
> I am not sure about that, when I am looking at writing a story for a
> web app, if I try and abstract the browser out of it, it stops making
> sense.
>
> You need to be sufficiently close to the metal to drive the implementation.
>
> Scenario: get index
>                 Given user is authenticated as admin
>                 And user is at manage library page
>
>                 When user clicks Manage Local Partners link
>
>                 Then user is brought to partners index
>
> Here is an example from an app I am working on.  The language 'clicks'
> and 'link' expressly imply that I am using a browser interface.
> I can definitely swap out the step implementation for safariwatir vs
> rails integration tests still.   How would you write a story like
> this?

I click links in desktop apps all the time, so I don't think this is
limited to webapps (though "get index" does seem to imply that).
"partners index" probably means "partners list", so how about this:

Scenario: visit partners list
               Given user is authenticated as admin
               And user is at manage library page

               When user clicks Manage Local Partners link

               Then user is brought to partners list

????

WDYT?

FWIW, I think that these sort of navigational scenarios should be
limited, but I don't think they should be excluded.

Cheers,
David

>
> Jake
>
> On Nov 7, 2007 12:08 PM, Daniel De Aguiar
>
> <ddeaguiar at archcreekconsulting.com> wrote:
> >
> > Stories should be technology agnostic. I don't think form references, for
> > example, have a place in them.
> >
> > I think technology-specific interaction story information is best captured
> > in a different way, particularly in a "non-executable" format.
> >
> > - Dan
> >
> > On Nov 7, 2007, at 10:28 AM, "Dan North" <tastapod at gmail.com> wrote:
> >
> >
> > Exactly. The behaviour description works in conjunction with other material
> > that help with the non-behavioural aspects, like screen layouts or design
> > guidelines. You would probably have a lo-fi mock-up of the login screen
> > (just a drawing) with the User and Password fields and Login button
> > labelled. Then the story would refer to those elements.
> >
> >
> > On 11/7/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> > > On Nov 7, 2007 2:04 AM, Matthijs Langenberg <mlangenberg at gmail.com> wrote:
> > > > Would this also mean that the guy writing the story is defining the
> > > > functional part of the GUI?
> > > > Since it's the most outer layer of the system, would that be described
> > in a
> > > > story first?
> > > > Like: "Given a user and a form with a button, when a user clicks the
> > button,
> > > > then the world should come to an end."
> > >
> > > There should likely be both interaction stories like that AND business
> > > rule stories, like the one Dan uses in
> > > http://dannorth.net/2007/06/introducing-rbehave . If every story takes
> > > you through every step, they all become too big IMO.
> > > _______________________________________________
> > > rspec-devel mailing list
> > > rspec-devel at rubyforge.org
> > > http://rubyforge.org/mailman/listinfo/rspec-devel
> > >
> >
> >
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/l