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/listinfo/rspec-devel
>

From jake.howerton at gmail.com  Wed Nov  7 12:41:35 2007
From: jake.howerton at gmail.com (Jake Howerton)
Date: Wed, 7 Nov 2007 12:41:35 -0500
Subject: [rspec-devel] Stories vs. examples
In-Reply-To: <57c63afe0711070935q150dd638hb76847b1a9c34146@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>
	<57c63afe0711070935q150dd638hb76847b1a9c34146@mail.gmail.com>
Message-ID: <218a05e40711070941q42a2b0c1j5489ddd908195a5f@mail.gmail.com>

You could even take out the word link

When user clicks Manage Local Partners

Then implement the step as clicking a link w/ that text in a browser,
or clicking a button w/ that label in a desktop GUI.  I guess the
issue is more of a diminishing returns one.  Should you spend extra
time abstracting your stories away from implementation that you cannot
even forsee planning, and if so why?

Obviously the situation is really different if you are developing a
desktop client and web interface simultaneously or it is planned in a
short period of time.

Jake


> 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/listinfo/rspec-devel
> >
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From pergesu at gmail.com  Wed Nov  7 13:23:18 2007
From: pergesu at gmail.com (Pat Maddox)
Date: Wed, 7 Nov 2007 10:23:18 -0800
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: <810a540e0711071023x774ada95oe611558bbb65904@mail.gmail.com>

On Nov 7, 2007 6:15 AM, 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.

I still haven't quite made up my mind about this.  At this point, I'm
expressing interactions in stories and business rules in specs.  I
don't really like Dan's account example - it's either too low-level
for my taste, or isn't quite low-level enough :)

Here's the account class as I would probably write it (completely
untested): http://pastie.caboo.se/115092

I could be picking nits here, and Dan and I just have a different
design style.  If I give an object a command, then I expect it to do
its work or fail hard.  So for the "savings account is overdrawn"
scenario, I'd need to work at a higher level or use the object in more
detail.  When doing Rails apps, I would just have a scenario where the
user submits a form, and the next page displays an error message and
the balances are unchanged.

I'm not certain of what to do if it's not a Rails app.  I might use a
higher abstraction such as a BankService which protects the user from
dirty exceptions.  So the transfer step might be

@transaction = bank_service.request_transfer @savings, @checking, 50
@transaction.should_not be_success
@transaction.error.should == "You do not have sufficient funds"

and then we'd still have the steps that verify the account balances
are unchanged.

Of course, now is the point where I admit that I think that's a
needless abstraction, and doesn't feel very OO to me.  But maybe you
reach a point where you do need to wrap it up like that.  I would much
prefer:

@savings.transfer_to @checking, 50 rescue nil

again later verifying that the balances weren't touched.

So what am I getting at here?  Right now, I generally only use stories
at a very high level.  That means I perform an action from the user's
point of view, rather than telling an object to do something.  In this
case, I would have a spec that defines when #can_transfer? is true and
when it's false, and that #transfer_to blows up when the account
doesn't have sufficient funds.  It's really a design detail though,
and one that should be hidden from the user.

However I mentioned that I'm on the fence about all of that.  The key
question is why am I writing code that isn't driven by a story?
Specifically, if the only interaction point is a controller action,
why do I need code that raises an exception instead of just silently
failing?  The reason is that a controller action is never the only
interaction point.  In a Rails app I happily open up console and use
my business objects.  I need them to be more informative when
something fails.

But, that's a business process, and needs to be captured in a story.
So basically this all boils down to me wondering if I need to move
more stuff - particularly interactions with business objects - into
stories.

Pat

From ddeaguiar at archcreekconsulting.com  Wed Nov  7 17:05:34 2007
From: ddeaguiar at archcreekconsulting.com (Daniel De Aguiar)
Date: Wed, 7 Nov 2007 17:05:34 -0500
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: <baf09abf0711071405k4583f753xdf5857e56c52aba2@mail.gmail.com>

In this case, the scenario is around the admins ability to retrieve local
partner info once they are logged in.

A simplified example:

Scenario: admin can retrieve local partner data
  Given a user is authenticated as an admin

  The user is able to retrieve a listing of local partners.


To me this captures the intent of the high-level requirement without
committing to an implementation early. To me stories are about 'What'  is
wanted (requirements) as opposed to 'How' it is done (implementation).

After further conversations with the users where the requirements are
explored in detail, the appropriate implementation is decided upon (i.e,
forms, page flows, fields, etc...). I would then focus on capturing these
implementation-specific details in traditional rspec tests.

Just my two cents...

-Dan

On 11/7/07, 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?
>
> 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/listinfo/rspec-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20071107/473d591b/attachment-0001.html 

From undees at gmail.com  Wed Nov  7 17:17:51 2007
From: undees at gmail.com (Ian Dees)
Date: Wed, 7 Nov 2007 14:17:51 -0800
Subject: [rspec-devel] Stories vs. examples
Message-ID: <ad4f9af90711071417v78b5f0e1qfe190100a6ed8e2a@mail.gmail.com>

Hi, all.

Wow, lots of thoughtful commentary.  Thanks, everyone!

Quoth Matthijs:

> Would this also mean that the guy writing the story is defining the
> functional part of the GUI?

In our shop, they're usually different people, though perhaps part of
that is because we're not using the Story Runner yet.  A designer
draws screen mockups and writes descriptions of what the controls and
dialogs do, her work gets dissected by a bunch of backseat drivers, a
tester writes the use cases, and then either the same tester or
another developer translates the use cases into RSpec (with the help
of some automation).

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

Funny you should mention that.  In a couple of months, I'm going to
need a couple more reviewers for just that reason.  Interested?

--Ian

From bryan at brynary.com  Wed Nov  7 13:47:49 2007
From: bryan at brynary.com (Bryan Helmkamp)
Date: Wed, 7 Nov 2007 13:47:49 -0500
Subject: [rspec-devel] Stories vs. examples
In-Reply-To: <810a540e0711071023x774ada95oe611558bbb65904@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>
	<810a540e0711071023x774ada95oe611558bbb65904@mail.gmail.com>
Message-ID: <BF7D03A7-A055-45D7-A43B-B6F6F5425AD7@brynary.com>

On Nov 7, 2007, at 1:23 PM, Pat Maddox wrote:
> But, that's a business process, and needs to be captured in a story.
> So basically this all boils down to me wondering if I need to move
> more stuff - particularly interactions with business objects - into
> stories.


I've been preferring declarative stories to imperative stories. So  
instead of:

Given an empty checking and savings account
And visiting the Money Transfer page
And typing transfer amount $20
And selecting from account "Checking"
And selecting to account "Savings"
When clicking "Transfer"
Then user should see error message "Insufficient funds"
And checking account should have balance $0
And savings accounts should have balance $0

What about:

Given an empty checking and savings account
When user tries transferring $20 from checking to savings
Then user should see message "Insufficient funds"
And checking account should have balance $0
And savings accounts should have balance $0

The clicks, typing and selects still happen behind the scenes, but  
aren't really important at the story level.

WDYT?

-Bryan

--
http://brynary.com -- My blog


From pergesu at gmail.com  Wed Nov  7 18:17:44 2007
From: pergesu at gmail.com (Pat Maddox)
Date: Wed, 7 Nov 2007 15:17:44 -0800
Subject: [rspec-devel] Stories vs. examples
In-Reply-To: <BF7D03A7-A055-45D7-A43B-B6F6F5425AD7@brynary.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>
	<810a540e0711071023x774ada95oe611558bbb65904@mail.gmail.com>
	<BF7D03A7-A055-45D7-A43B-B6F6F5425AD7@brynary.com>
Message-ID: <810a540e0711071517l5c6f0c99q280f3379faf8a53@mail.gmail.com>

On Nov 7, 2007 10:47 AM, Bryan Helmkamp <bryan at brynary.com> wrote:
> On Nov 7, 2007, at 1:23 PM, Pat Maddox wrote:
> > But, that's a business process, and needs to be captured in a story.
> > So basically this all boils down to me wondering if I need to move
> > more stuff - particularly interactions with business objects - into
> > stories.
>
>
> I've been preferring declarative stories to imperative stories. So
> instead of:
>
> Given an empty checking and savings account
> And visiting the Money Transfer page
> And typing transfer amount $20
> And selecting from account "Checking"
> And selecting to account "Savings"
> When clicking "Transfer"
> Then user should see error message "Insufficient funds"
> And checking account should have balance $0
> And savings accounts should have balance $0
>
> What about:
>
> Given an empty checking and savings account
> When user tries transferring $20 from checking to savings
> Then user should see message "Insufficient funds"
> And checking account should have balance $0
> And savings accounts should have balance $0
>
> The clicks, typing and selects still happen behind the scenes, but
> aren't really important at the story level.
>
> WDYT?

That really isn't anything like what I was discussing :)  but I agree
that the second form is much better imo.

Pat

From jake.howerton at gmail.com  Wed Nov  7 18:39:43 2007
From: jake.howerton at gmail.com (Jake Howerton)
Date: Wed, 7 Nov 2007 18:39:43 -0500
Subject: [rspec-devel] Stories vs. examples
In-Reply-To: <BF7D03A7-A055-45D7-A43B-B6F6F5425AD7@brynary.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>
	<810a540e0711071023x774ada95oe611558bbb65904@mail.gmail.com>
	<BF7D03A7-A055-45D7-A43B-B6F6F5425AD7@brynary.com>
Message-ID: <218a05e40711071539o756810cayb5eeb554662ea99c@mail.gmail.com>

The question is ... where do we want to abstract.  If we abstract in
the stories you might come up with the bottom example.  Although I
think the top could be written alot more succintly than its current
form.  If we abstract in the steps, we might have more verbose
stories, but the steps can be much more reusable and less actual code
would get written.

Honestly most of my existing stories ( Not actually written by me)
map much better to the detailed implementation than the abstract.
Stories that get written by non programmers are going to have data in
them.   "When I click on the Widgets Inc logo it blows up!" etc.

Jake

> Given an empty checking and savings account
> And visiting the Money Transfer page
> And typing transfer amount $20
> And selecting from account "Checking"
> And selecting to account "Savings"
> When clicking "Transfer"
> Then user should see error message "Insufficient funds"
> And checking account should have balance $0
> And savings accounts should have balance $0
>
> What about:
>
> Given an empty checking and savings account
> When user tries transferring $20 from checking to savings
> Then user should see message "Insufficient funds"
> And checking account should have balance $0
> And savings accounts should have balance $0
>
> The clicks, typing and selects still happen behind the scenes, but
> aren't really important at the story level.

From tastapod at gmail.com  Wed Nov  7 18:52:48 2007
From: tastapod at gmail.com (Dan North)
Date: Wed, 7 Nov 2007 23:52:48 +0000
Subject: [rspec-devel] Stories vs. examples
In-Reply-To: <218a05e40711071539o756810cayb5eeb554662ea99c@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>
	<810a540e0711071023x774ada95oe611558bbb65904@mail.gmail.com>
	<BF7D03A7-A055-45D7-A43B-B6F6F5425AD7@brynary.com>
	<218a05e40711071539o756810cayb5eeb554662ea99c@mail.gmail.com>
Message-ID: <d559d8430711071552g3555a5b7l7bbc6bf348ebad8b@mail.gmail.com>

The thing to bear in mind is that there are two different domains going on
for the user at the acceptance testing (scenario) level. There is the domain
of the business problem (transfer funds, authenticate yourself) and the
domain of the UI technology (navigate, click, type). The problems start when
you mix the two domain vocabularies.

The scenarios should be purely in business terms, so that you should be able
to replace a web app with a console app or a rich client or some people
running around with pieces of paper, and the scenario still makes sense. If
you have to change the wording in the scenario then it means you've confused
your levels of abstraction - your implementation UI vocabulary has leaked
into your scenario descriptions. This is usually a Bad Thing. That's why
your second example reads so much more naturally - it's how a business
stakeholder would describe the scenario independent of the technology.

In your step implementations (the "body" of each step) you would expect to
see code driving the implementing technology, say a browser. WebDriver (
http://code.google.com/p/webdriver/wiki/GettingStarted) or the Selenium
runner (http://tinyurl.com/ytls64 - sorry it's using Test::Unit) are good
examples of this.

Cheers,
Dan

On 11/7/07, Jake Howerton <jake.howerton at gmail.com> wrote:
>
> The question is ... where do we want to abstract.  If we abstract in
> the stories you might come up with the bottom example.  Although I
> think the top could be written alot more succintly than its current
> form.  If we abstract in the steps, we might have more verbose
> stories, but the steps can be much more reusable and less actual code
> would get written.
>
> Honestly most of my existing stories ( Not actually written by me)
> map much better to the detailed implementation than the abstract.
> Stories that get written by non programmers are going to have data in
> them.   "When I click on the Widgets Inc logo it blows up!" etc.
>
> Jake
>
> > Given an empty checking and savings account
> > And visiting the Money Transfer page
> > And typing transfer amount $20
> > And selecting from account "Checking"
> > And selecting to account "Savings"
> > When clicking "Transfer"
> > Then user should see error message "Insufficient funds"
> > And checking account should have balance $0
> > And savings accounts should have balance $0
> >
> > What about:
> >
> > Given an empty checking and savings account
> > When user tries transferring $20 from checking to savings
> > Then user should see message "Insufficient funds"
> > And checking account should have balance $0
> > And savings accounts should have balance $0
> >
> > The clicks, typing and selects still happen behind the scenes, but
> > aren't really important at the story level.
> _______________________________________________
> 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/1761f482/attachment.html 

From bryan at brynary.com  Wed Nov  7 18:19:36 2007
From: bryan at brynary.com (Bryan Helmkamp)
Date: Wed, 7 Nov 2007 18:19:36 -0500
Subject: [rspec-devel] Stories vs. examples
In-Reply-To: <baf09abf0711071405k4583f753xdf5857e56c52aba2@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>
	<baf09abf0711071405k4583f753xdf5857e56c52aba2@mail.gmail.com>
Message-ID: <DDAD34BD-B7EB-4260-8999-895D76BDF0F5@brynary.com>

On Nov 7, 2007, at 5:05 PM, Daniel De Aguiar wrote:
> Scenario: admin can retrieve local partner data
>   Given a user is authenticated as an admin
>
>   The user is able to retrieve a listing of local partners.
>
>
> To me this captures the intent of the high-level requirement without  
> committing to an implementation early. To me stories are about  
> 'What'  is wanted (requirements) as opposed to 'How' it is done  
> (implementation).


When testing, we're constantly choosing medium points between   
"Application.should work" and a much more fine-grained level. This  
seems more like a Story than a Scenario. For example:

"As an admin, I want to retrieve a listing of local partners."

Scenarios would then be written to flesh out edge cases like "What if  
the partner is currently blah bleh blah blah?"

-Bryan

--
http://brynary.com -- My blog


From bryan at brynary.com  Wed Nov  7 18:20:23 2007
From: bryan at brynary.com (Bryan Helmkamp)
Date: Wed, 7 Nov 2007 18:20:23 -0500
Subject: [rspec-devel] Stories vs. examples
In-Reply-To: <ad4f9af90711071417v78b5f0e1qfe190100a6ed8e2a@mail.gmail.com>
References: <ad4f9af90711071417v78b5f0e1qfe190100a6ed8e2a@mail.gmail.com>
Message-ID: <ADF708C8-449B-41BD-8318-3BBDC326695A@brynary.com>

On Nov 7, 2007, at 5:17 PM, Ian Dees wrote:
> then either the same tester or
> another developer translates the use cases into RSpec (with the help
> of some automation).

Ian,

Care to share any details on the kind of automation you've got for  
this right now?

-Bryan

--
http://brynary.com -- My blog


From jake.howerton at gmail.com  Wed Nov  7 23:33:23 2007
From: jake.howerton at gmail.com (Jake Howerton)
Date: Wed, 7 Nov 2007 23:33:23 -0500
Subject: [rspec-devel] Story implementation and custom matchers
Message-ID: <218a05e40711072033m404fa0b2s91f62ee9fab01d3@mail.gmail.com>

Is there currently a hook to load in custom matchers for the story runner?
I am looking for the equivalent to config.include(CustomMatchers) in
the normal rspec runner

From dchelimsky at gmail.com  Wed Nov  7 23:36:43 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 7 Nov 2007 22:36:43 -0600
Subject: [rspec-devel] Story implementation and custom matchers
In-Reply-To: <218a05e40711072033m404fa0b2s91f62ee9fab01d3@mail.gmail.com>
References: <218a05e40711072033m404fa0b2s91f62ee9fab01d3@mail.gmail.com>
Message-ID: <57c63afe0711072036y65fba3adva4741bb994fa4c8e@mail.gmail.com>

On Nov 7, 2007 10:33 PM, Jake Howerton <jake.howerton at gmail.com> wrote:
> Is there currently a hook to load in custom matchers for the story runner?
> I am looking for the equivalent to config.include(CustomMatchers) in
> the normal rspec runner

The only hook is :type => SomeClass. You could either subclass
RailsStory and add your matchers to that, or just open it up and
include modules with your matchers. I haven't tried either, but they
*should* work.

Cheers,
David

From dchelimsky at gmail.com  Wed Nov  7 23:45:36 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 7 Nov 2007 22:45:36 -0600
Subject: [rspec-devel] Story implementation and custom matchers
In-Reply-To: <57c63afe0711072036y65fba3adva4741bb994fa4c8e@mail.gmail.com>
References: <218a05e40711072033m404fa0b2s91f62ee9fab01d3@mail.gmail.com>
	<57c63afe0711072036y65fba3adva4741bb994fa4c8e@mail.gmail.com>
Message-ID: <57c63afe0711072045o20be1e4yd0c4ad39759694e@mail.gmail.com>

On Nov 7, 2007 10:36 PM, David Chelimsky <dchelimsky at gmail.com> wrote:
> On Nov 7, 2007 10:33 PM, Jake Howerton <jake.howerton at gmail.com> wrote:
> > Is there currently a hook to load in custom matchers for the story runner?
> > I am looking for the equivalent to config.include(CustomMatchers) in
> > the normal rspec runner
>
> The only hook is :type => SomeClass. You could either subclass
> RailsStory and add your matchers to that, or just open it up and
> include modules with your matchers. I haven't tried either, but they
> *should* work.

I just tried the latter in a rails app and it works as expected. The
only danger is collisions as your helper/matcher libraries grow. If
that is not a concern, I'd say the simplest would be to add
matchers/helpers to modules and include them in RailsStory. Otherwise,
subclass it and use specific subs for each Story.

If you're not writing a rails app, then you'll need a base class of
some kind (by default, stories run in an instance of Object) to
include your modules in - or just define arbitrary objects with the
helpers/matchers embedded directly.

What we REALLY need is a way to define scoped matchers/helpers right
alongside the steps. Coming eventually ...

Cheers,
David

From undees at gmail.com  Thu Nov  8 02:25:23 2007
From: undees at gmail.com (Ian Dees)
Date: Wed, 7 Nov 2007 23:25:23 -0800
Subject: [rspec-devel] Stories vs. examples
Message-ID: <ad4f9af90711072325v7dea54dv69328ae35a87a1fb@mail.gmail.com>

Says me:

> > then either the same tester or
> > another developer translates the use cases into RSpec (with the help
> > of some automation).

Quoth Bryan:

> Care to share any details on the kind of automation you've got for
> this right now?

Sure.  We use a requirements management tool (not nearly as dreadful
as it sounds; in fact, it almost exactly matches what I used to do by
hand in Excel, but more reliably) to write our test cases and document
which requirements they address.

We then use the tool's built-in scripting language (an insane pidgin
that's been referred to as "designed by a committee that's never met")
to spit out a new Ruby file with a "describe" block per test case and
an "it" block for each _step_ of the test case.  The meatier parts of
the test case get injected as Ruby comments.  We fill in the behavior
of each test to get 'em from "pending" to "passed," and attach the
completed RSpec scripts to the test case.

So now we can direct the RSpec UI tests from the requirements
management tool: we run a script that takes one or more test cases,
does some hideous OLE magic to get the Ruby code into the file system,
runs RSpec, and logs the results back into the tool.

We can probably cut down on some of those steps if we move to the
Story Runner, which is why I'm particularly interested in where the
plain text runner stuff is going.

--Ian

From noreply at rubyforge.org  Thu Nov  8 02:37:11 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu,  8 Nov 2007 02:37:11 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-15446 ] Removed duplicate word in
	with_steps_for comment.
Message-ID: <20071108073711.C2DE118586BD@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Daniel De Aguiar (drdan)
Assigned to: Nobody (None)
Summary: Removed duplicate word in with_steps_for comment.

Initial Comment:
In the with_steps_for comment, The word 'Steps' is duplicated On line 33 of main.rb.

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

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

From noreply at rubyforge.org  Thu Nov  8 07:06:54 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu,  8 Nov 2007 07:06:54 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-15446 ] Removed duplicate word in
	with_steps_for comment.
Message-ID: <20071108120654.23F631858693@rubyforge.org>

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

Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Daniel De Aguiar (drdan)
Assigned to: Nobody (None)
Summary: Removed duplicate word in with_steps_for comment.

Initial Comment:
In the with_steps_for comment, The word 'Steps' is duplicated On line 33 of main.rb.

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

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

Message:
Applied to r2824.

Please, even for something so minor, patch from the root of the trunk.

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

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

From brandon at collectiveidea.com  Thu Nov  8 10:20:00 2007
From: brandon at collectiveidea.com (Brandon Keepers)
Date: Thu, 8 Nov 2007 10:20:00 -0500
Subject: [rspec-devel] Rails #8115 and spec/matchers/have
Message-ID: <73460037-0E2D-44E2-9C3F-EB95CF34B93C@collectiveidea.com>

Rails commit #8115 refactored how plugins are loaded and now adds all  
the vendor/plugins/*/lib directories to the load path before  
initializing all the plugins.

rspec and rspec_on_rails both have spec/matchers/have.rb, and now that  
they're both in the load path, when rspec initializes and requires  
spec/matchers/have, the rspec_on_rails version gets loaded.

This seems to only happen when I run integration tests and not specs  
(stack trace below).  The ways I see to fix this are 1) require these  
using an absolute path or 2) rename the rails one to spec/rails/ 
matchers/have, or something along those lines.

I'd be happy to submit a patch, let me know what you think about ways  
to get around this.

Brandon





/Users/brandon/projects/dealerflow/vendor/plugins/rspec_on_rails/lib/ 
spec/matchers/have.rb:4:in `alias_method': undefined method  
`failure_message' for class `Spec::Matchers::Have' (NameError)
	from /Users/brandon/projects/dealerflow/vendor/plugins/rspec_on_rails/ 
lib/spec/matchers/have.rb:4
	from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ 
ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require'
	from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ 
ruby/1.8/rubygems/custom_require.rb:27:in `require'
	from /Users/brandon/projects/dealerflow/vendor/rails/activerecord/ 
lib/../../activesupport/lib/active_support/dependencies.rb:496:in  
`require'
	from /Users/brandon/projects/dealerflow/vendor/rails/activerecord/ 
lib/../../activesupport/lib/active_support/dependencies.rb:342:in  
`new_constants_in'
	from /Users/brandon/projects/dealerflow/vendor/rails/activerecord/ 
lib/../../activesupport/lib/active_support/dependencies.rb:496:in  
`require'
	from /Users/brandon/projects/dealerflow/vendor/plugins/rspec_on_rails/ 
lib/spec/matchers.rb:3
	from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ 
ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require'
	 ... 28 levels...
	from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ 
ruby/gems/1.8/gems/rake-0.7.3/lib/rake/rake_test_loader.rb:5:in `load'
	from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ 
ruby/gems/1.8/gems/rake-0.7.3/lib/rake/rake_test_loader.rb:5
	from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ 
ruby/gems/1.8/gems/rake-0.7.3/lib/rake/rake_test_loader.rb:5:in `each'
	from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ 
ruby/gems/1.8/gems/rake-0.7.3/lib/rake/rake_test_loader.rb:5
Errors running test:integration!
~/projects/dealerflow brandon$


From dchelimsky at gmail.com  Thu Nov  8 12:29:30 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Thu, 8 Nov 2007 11:29:30 -0600
Subject: [rspec-devel] Rails #8115 and spec/matchers/have
In-Reply-To: <73460037-0E2D-44E2-9C3F-EB95CF34B93C@collectiveidea.com>
References: <73460037-0E2D-44E2-9C3F-EB95CF34B93C@collectiveidea.com>
Message-ID: <57c63afe0711080929t3ed44033pd09352d1e33a9994@mail.gmail.com>

On Nov 8, 2007 9:20 AM, Brandon Keepers <brandon at collectiveidea.com> wrote:
> Rails commit #8115 refactored how plugins are loaded and now adds all
> the vendor/plugins/*/lib directories to the load path before
> initializing all the plugins.
>
> rspec and rspec_on_rails both have spec/matchers/have.rb, and now that
> they're both in the load path, when rspec initializes and requires
> spec/matchers/have, the rspec_on_rails version gets loaded.
>
> This seems to only happen when I run integration tests and not specs
> (stack trace below).  The ways I see to fix this are 1) require these
> using an absolute path or 2) rename the rails one to spec/rails/
> matchers/have, or something along those lines.
>
> I'd be happy to submit a patch, let me know what you think about ways
> to get around this.

A patch would be awesome - thanks!

How about moving it from rspec_on_rails/lib/spec/matchers/have to
rspec_on_rails/lib/extensions/spec/matchers/have and include require
'spec/matchers/have' from within that file.

That file monkey patches Spec::Matchers::Have and I think putting
under an extensions directory makes sense.

WDYT?

>
> Brandon
>
>
>
>
>
> /Users/brandon/projects/dealerflow/vendor/plugins/rspec_on_rails/lib/
> spec/matchers/have.rb:4:in `alias_method': undefined method
> `failure_message' for class `Spec::Matchers::Have' (NameError)
>         from /Users/brandon/projects/dealerflow/vendor/plugins/rspec_on_rails/
> lib/spec/matchers/have.rb:4
>         from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/
> ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require'
>         from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/
> ruby/1.8/rubygems/custom_require.rb:27:in `require'
>         from /Users/brandon/projects/dealerflow/vendor/rails/activerecord/
> lib/../../activesupport/lib/active_support/dependencies.rb:496:in
> `require'
>         from /Users/brandon/projects/dealerflow/vendor/rails/activerecord/
> lib/../../activesupport/lib/active_support/dependencies.rb:342:in
> `new_constants_in'
>         from /Users/brandon/projects/dealerflow/vendor/rails/activerecord/
> lib/../../activesupport/lib/active_support/dependencies.rb:496:in
> `require'
>         from /Users/brandon/projects/dealerflow/vendor/plugins/rspec_on_rails/
> lib/spec/matchers.rb:3
>         from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/
> ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require'
>          ... 28 levels...
>         from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/
> ruby/gems/1.8/gems/rake-0.7.3/lib/rake/rake_test_loader.rb:5:in `load'
>         from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/
> ruby/gems/1.8/gems/rake-0.7.3/lib/rake/rake_test_loader.rb:5
>         from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/
> ruby/gems/1.8/gems/rake-0.7.3/lib/rake/rake_test_loader.rb:5:in `each'
>         from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/
> ruby/gems/1.8/gems/rake-0.7.3/lib/rake/rake_test_loader.rb:5
> Errors running test:integration!
> ~/projects/dealerflow brandon$
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From bkeepers at gmail.com  Thu Nov  8 12:06:30 2007
From: bkeepers at gmail.com (Brandon Keepers)
Date: Thu, 8 Nov 2007 12:06:30 -0500
Subject: [rspec-devel] Rails #8115 and spec/matchers/have
Message-ID: <B69B3582-BD6E-408E-8E5B-39B5A1C8BE89@gmail.com>

Rails commit #8115 refactored how plugins are loaded and now adds all  
the vendor/plugins/*/lib directories to the load path before  
initializing all the plugins.

rspec and rspec_on_rails both have spec/matchers/have.rb, and now that  
they're both in the load path, when rspec initializes and requires  
spec/matchers/have, the rspec_on_rails version gets loaded.

This seems to only happen when I run integration tests and not specs  
(stack trace below).  The ways I see to fix this are 1) require these  
using an absolute path or 2) rename the rails one to spec/rails/ 
matchers/have, or something along those lines.

I'd be happy to submit a patch, let me know what you think about ways  
to get around this.

Brandon





/Users/brandon/projects/dealerflow/vendor/plugins/rspec_on_rails/lib/ 
spec/matchers/have.rb:4:in `alias_method': undefined method  
`failure_message' for class `Spec::Matchers::Have' (NameError)
	from /Users/brandon/projects/dealerflow/vendor/plugins/rspec_on_rails/ 
lib/spec/matchers/have.rb:4
	from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ 
ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require'
	from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ 
ruby/1.8/rubygems/custom_require.rb:27:in `require'
	from /Users/brandon/projects/dealerflow/vendor/rails/activerecord/ 
lib/../../activesupport/lib/active_support/dependencies.rb:496:in  
`require'
	from /Users/brandon/projects/dealerflow/vendor/rails/activerecord/ 
lib/../../activesupport/lib/active_support/dependencies.rb:342:in  
`new_constants_in'
	from /Users/brandon/projects/dealerflow/vendor/rails/activerecord/ 
lib/../../activesupport/lib/active_support/dependencies.rb:496:in  
`require'
	from /Users/brandon/projects/dealerflow/vendor/plugins/rspec_on_rails/ 
lib/spec/matchers.rb:3
	from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ 
ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require'
	 ... 28 levels...
	from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ 
ruby/gems/1.8/gems/rake-0.7.3/lib/rake/rake_test_loader.rb:5:in `load'
	from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ 
ruby/gems/1.8/gems/rake-0.7.3/lib/rake/rake_test_loader.rb:5
	from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ 
ruby/gems/1.8/gems/rake-0.7.3/lib/rake/rake_test_loader.rb:5:in `each'
	from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ 
ruby/gems/1.8/gems/rake-0.7.3/lib/rake/rake_test_loader.rb:5
Errors running test:integration!
~/projects/dealerflow brandon$


From noreply at rubyforge.org  Thu Nov  8 14:20:20 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu,  8 Nov 2007 14:20:20 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-13208 ] Specdoc outputs wrong spec names
	with drbserver
Message-ID: <20071108192020.5F0DF1598080@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 4
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: Specdoc outputs wrong spec names with drbserver

Initial Comment:

In a rails project (trunk, rev. 7345, ruby 1.8.6, Mac OS X, Rspec & rspec on rails frozen in /vendor/plugins at current release, 1.0.8), with the following spec.opts:

--colour

--loadby mtime
--reverse
--drb
--format specdoc

The output looks as follows:

ptolemy# rake spec
(in /Users/smt/src/web/urbis/branches/rails_2.0_integration)

      *******************************************************************
      * config.breakpoint_server has been deprecated and has no effect. *
      *******************************************************************
      

#<DRb::DRbUnknown:0x14e7298>
- should have the unit name
- should have the keyword
- should ensure that each unit_name is unique

#<DRb::DRbUnknown:0x14b4604>
- should add the error 'Wrong category for this item' on validation of the attempt if the goal's category is equal to the item's category (PENDING: Not Yet Implemented)
- should add the error 'Wrong category for this item' on validation of the attempt if the goal's category is nil (PENDING: Not Yet Implemented)


Obviously the class names/description blocks are not being displayed properly.




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

Comment By: Chris Scharf (scharfie)
Date: 2007-11-08 19:20

Message:
I believe I have found the fix for this.  In the behaviour.rb file for RSpec (rspec/lib/spec/dsl/behaviour.rb) change the following line in the run method:

  reporter.add_behaviour(@description)

to 

  reporter.add_behaviour(@description.to_s)

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-08-20 08:43

Message:
This is happening because Behaviour is not serializable. I'll look into this one.

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

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

From noreply at rubyforge.org  Thu Nov  8 14:31:05 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu,  8 Nov 2007 14:31:05 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-15461 ] RaiseError should give at
	least the first line of backtrace when it encounters an
	unexpected exception
Message-ID: <20071108193105.A7143159807C@rubyforge.org>

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

Category: expectation module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Alan Shields (sshields)
Assigned to: Nobody (None)
Summary: RaiseError should give at least the first line of backtrace when it encounters an unexpected exception

Initial Comment:
which is more useful:

NoMethodError in 'blah... should allow the user object to be passed in'
undefined method `null?' for #<User:0x34cf81c>
/Users/sshields/code/appsw/config/../vendor/plugins/dollars_and_cents/lib/dollars_and_cents.rb:48:in `method_missing'
./spec/models/blah_spec.rb:46:
script/spec:4:

ooooor

'blah... should allow the user object to be passed in' FAILED
expected no Exception, got #<NoMethodError: You have a nil object when you didn't expect it!
The error occurred while evaluating nil.to_time> from /Users/sshields/code/appsw/config/../app/models/calculation.rb:329:in `compute_range_rollup'
./spec/models/calculation_spec.rb:49:
script/spec:4:

Work paid for by 6bar8.com - makers of sweetspot.dm

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

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

From joshknowles at gmail.com  Thu Nov  8 14:58:15 2007
From: joshknowles at gmail.com (Josh Knowles)
Date: Thu, 8 Nov 2007 14:58:15 -0500
Subject: [rspec-devel] Story Directory Structure
Message-ID: <c18843c60711081158n7e4df445r955881761fb25953@mail.gmail.com>

  Throwing all of my stories, steps, helpers, etc into one dir is a
bit to cluttered for my OCD, so I've done the following:
http://pastie.caboo.se/115574.

How is everyone else arranging their stories directory?

-- 
Josh Knowles
phone: 509-979-1593
email:  joshknowles at gmail.com
web:    http://joshknowles.com

From dchelimsky at gmail.com  Thu Nov  8 15:29:54 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Thu, 8 Nov 2007 14:29:54 -0600
Subject: [rspec-devel] Story Directory Structure
In-Reply-To: <c18843c60711081158n7e4df445r955881761fb25953@mail.gmail.com>
References: <c18843c60711081158n7e4df445r955881761fb25953@mail.gmail.com>
Message-ID: <57c63afe0711081229y4e1a185el8f26878aa38c0f40@mail.gmail.com>

On Nov 8, 2007 1:58 PM, Josh Knowles <joshknowles at gmail.com> wrote:
>   Throwing all of my stories, steps, helpers, etc into one dir is a
> bit to cluttered for my OCD, so I've done the following:
> http://pastie.caboo.se/115574.
>
> How is everyone else arranging their stories directory?

Here's one of mine.

http://blog.davidchelimsky.net/files/stories_directory.jpg

The steps are organized by concept rather than by story. The
stories.rb file in each subdirectory runs just the stories in that
sub, while stories/all.rb runs them all.

David

From dchelimsky at gmail.com  Thu Nov  8 15:44:55 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Thu, 8 Nov 2007 14:44:55 -0600
Subject: [rspec-devel] Rails #8115 and spec/matchers/have
In-Reply-To: <57c63afe0711080929t3ed44033pd09352d1e33a9994@mail.gmail.com>
References: <73460037-0E2D-44E2-9C3F-EB95CF34B93C@collectiveidea.com>
	<57c63afe0711080929t3ed44033pd09352d1e33a9994@mail.gmail.com>
Message-ID: <57c63afe0711081244t286a1794q1cf45274ad75c7ab@mail.gmail.com>

On Nov 8, 2007 11:29 AM, David Chelimsky <dchelimsky at gmail.com> wrote:
> On Nov 8, 2007 9:20 AM, Brandon Keepers <brandon at collectiveidea.com> wrote:
> > Rails commit #8115 refactored how plugins are loaded and now adds all
> > the vendor/plugins/*/lib directories to the load path before
> > initializing all the plugins.
> >
> > rspec and rspec_on_rails both have spec/matchers/have.rb, and now that
> > they're both in the load path, when rspec initializes and requires
> > spec/matchers/have, the rspec_on_rails version gets loaded.
> >
> > This seems to only happen when I run integration tests and not specs
> > (stack trace below).  The ways I see to fix this are 1) require these
> > using an absolute path or 2) rename the rails one to spec/rails/
> > matchers/have, or something along those lines.
> >
> > I'd be happy to submit a patch, let me know what you think about ways
> > to get around this.
>
> A patch would be awesome - thanks!
>
> How about moving it from rspec_on_rails/lib/spec/matchers/have to
> rspec_on_rails/lib/extensions/spec/matchers/have and include require
> 'spec/matchers/have' from within that file.
>
> That file monkey patches Spec::Matchers::Have and I think putting
> under an extensions directory makes sense.
>
> WDYT?

Actually - I'll take care of this - should have it committed in a few.

From noreply at rubyforge.org  Thu Nov  8 15:47:07 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu,  8 Nov 2007 15:47:07 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15465 ] Edge rails #8115 changed plugin
	loading, causing conflic between rspec and rails plugin
Message-ID: <20071108204707.F26B51858661@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Brandon Keepers (brandon)
Assigned to: Nobody (None)
Summary: Edge rails #8115 changed plugin loading, causing conflic between rspec and rails plugin

Initial Comment:
Rails commit #8115 refactored how plugins are loaded and now adds all  
the vendor/plugins/*/lib directories to the load path before  
initializing all the plugins.

rspec and rspec_on_rails have some conflicting relative paths, so when rspec initializes, the rspec_on_rails version of some files gets loaded.

Attached is a patch that switches to absolute paths for some of the conflicting require statements, and moves spec/matchers and spec/dsl into an extensions/ directory in the rspec_on_rails plugin.

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

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

From joshknowles at gmail.com  Thu Nov  8 15:59:19 2007
From: joshknowles at gmail.com (Josh Knowles)
Date: Thu, 8 Nov 2007 15:59:19 -0500
Subject: [rspec-devel] Story Directory Structure
In-Reply-To: <57c63afe0711081229y4e1a185el8f26878aa38c0f40@mail.gmail.com>
References: <c18843c60711081158n7e4df445r955881761fb25953@mail.gmail.com>
	<57c63afe0711081229y4e1a185el8f26878aa38c0f40@mail.gmail.com>
Message-ID: <c18843c60711081259o2e27edela5d27d6b7badd118@mail.gmail.com>

On 11/8/07, David Chelimsky <dchelimsky at gmail.com> wrote:
>
> The steps are organized by concept rather than by story. The
> stories.rb file in each subdirectory runs just the stories in that
> sub, while stories/all.rb runs them all.

I like how you've structured this.  Do you find that all steps fall
into concepts, or are you also defining story specific steps within
the stories.rb?

Do you feel there's a long-term need for all.rb or should it be
replaced with a rake task?

-- 
Josh Knowles
phone: 509-979-1593
email:  joshknowles at gmail.com
web:    http://joshknowles.com

From dchelimsky at gmail.com  Thu Nov  8 16:02:46 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Thu, 8 Nov 2007 15:02:46 -0600
Subject: [rspec-devel] Story Directory Structure
In-Reply-To: <c18843c60711081259o2e27edela5d27d6b7badd118@mail.gmail.com>
References: <c18843c60711081158n7e4df445r955881761fb25953@mail.gmail.com>
	<57c63afe0711081229y4e1a185el8f26878aa38c0f40@mail.gmail.com>
	<c18843c60711081259o2e27edela5d27d6b7badd118@mail.gmail.com>
Message-ID: <57c63afe0711081302n1fba06a8t85d93611c8c4af@mail.gmail.com>

On Nov 8, 2007 2:59 PM, Josh Knowles <joshknowles at gmail.com> wrote:
> On 11/8/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> >
> > The steps are organized by concept rather than by story. The
> > stories.rb file in each subdirectory runs just the stories in that
> > sub, while stories/all.rb runs them all.
>
> I like how you've structured this.  Do you find that all steps fall
> into concepts, or are you also defining story specific steps within
> the stories.rb?
>
> Do you feel there's a long-term need for all.rb or should it be
> replaced with a rake task?

There IS a rake task:

rake stories

It calls stories/all.rb :)

However, I don't think we have enough experience/convention to know
what that rake task should do - right now I get to define whatever I
want in all.rb. Simpler that way, in my view.

WDYT?

>
>
> --
> Josh Knowles
> phone: 509-979-1593
> email:  joshknowles at gmail.com
> web:    http://joshknowles.com
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From joshknowles at gmail.com  Thu Nov  8 16:38:23 2007
From: joshknowles at gmail.com (Josh Knowles)
Date: Thu, 8 Nov 2007 16:38:23 -0500
Subject: [rspec-devel] Story Directory Structure
In-Reply-To: <57c63afe0711081302n1fba06a8t85d93611c8c4af@mail.gmail.com>
References: <c18843c60711081158n7e4df445r955881761fb25953@mail.gmail.com>
	<57c63afe0711081229y4e1a185el8f26878aa38c0f40@mail.gmail.com>
	<c18843c60711081259o2e27edela5d27d6b7badd118@mail.gmail.com>
	<57c63afe0711081302n1fba06a8t85d93611c8c4af@mail.gmail.com>
Message-ID: <c18843c60711081338u18039a34i231e72dfef09f9c2@mail.gmail.com>

On 11/8/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> There IS a rake task:
>
> rake stories
>

$ rake -T | grep stories
$

I must be missing something as I don't see the rake task described anywhere.

> However, I don't think we have enough experience/convention to know
> what that rake task should do - right now I get to define whatever I
> want in all.rb. Simpler that way, in my view.
>
> WDYT?

Makes sense.  This allows folks to structure their stories however they'd like.


-- 
Josh Knowles
phone: 509-979-1593
email:  joshknowles at gmail.com
web:    http://joshknowles.com

From noreply at rubyforge.org  Thu Nov  8 16:38:58 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu,  8 Nov 2007 16:38:58 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15465 ] Edge rails #8115 changed plugin
	loading, causing conflic between rspec and rails plugin
Message-ID: <20071108213858.E24F3159807A@rubyforge.org>

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

Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Brandon Keepers (brandon)
Assigned to: Nobody (None)
Summary: Edge rails #8115 changed plugin loading, causing conflic between rspec and rails plugin

Initial Comment:
Rails commit #8115 refactored how plugins are loaded and now adds all  
the vendor/plugins/*/lib directories to the load path before  
initializing all the plugins.

rspec and rspec_on_rails have some conflicting relative paths, so when rspec initializes, the rspec_on_rails version of some files gets loaded.

Attached is a patch that switches to absolute paths for some of the conflicting require statements, and moves spec/matchers and spec/dsl into an extensions/ directory in the rspec_on_rails plugin.

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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-08 21:38

Message:
Hey Brandon - sorry man - we crossed paths on this and I had already made the change, but only 1/2 of it - good catch on configuration also.

Just an FYI - I think you forgot to svn add before making the patch - it has the deletes, but not the adds. I resolved that on this end and moved a bunch of other stuff around as well.

Applied to r2831.

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

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

From dchelimsky at gmail.com  Thu Nov  8 16:40:17 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Thu, 8 Nov 2007 15:40:17 -0600
Subject: [rspec-devel] Story Directory Structure
In-Reply-To: <c18843c60711081338u18039a34i231e72dfef09f9c2@mail.gmail.com>
References: <c18843c60711081158n7e4df445r955881761fb25953@mail.gmail.com>
	<57c63afe0711081229y4e1a185el8f26878aa38c0f40@mail.gmail.com>
	<c18843c60711081259o2e27edela5d27d6b7badd118@mail.gmail.com>
	<57c63afe0711081302n1fba06a8t85d93611c8c4af@mail.gmail.com>
	<c18843c60711081338u18039a34i231e72dfef09f9c2@mail.gmail.com>
Message-ID: <57c63afe0711081340o2ab50ebai2b070c4be6ecfaf4@mail.gmail.com>

On Nov 8, 2007 3:38 PM, Josh Knowles <joshknowles at gmail.com> wrote:
> On 11/8/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> > There IS a rake task:
> >
> > rake stories
> >
>
> $ rake -T | grep stories
> $
>
> I must be missing something as I don't see the rake task described anywhere.

LOL - there is in MY project - just not in the plugin! (sorry to lead
you astray)

I think it's best left that way for the time being.

>
> > However, I don't think we have enough experience/convention to know
> > what that rake task should do - right now I get to define whatever I
> > want in all.rb. Simpler that way, in my view.
> >
> > WDYT?
>
> Makes sense.  This allows folks to structure their stories however they'd like.

Yes - which for the near term is a GOOD THING.

Cheers,
David

From noreply at rubyforge.org  Thu Nov  8 21:45:19 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu,  8 Nov 2007 21:45:19 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-15471 ] [PATCH] "better" handling of
	with(:foo)
Message-ID: <20071109024519.1C61F18585F0@rubyforge.org>

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

Category: mock module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Pat Maddox (pergesu)
Assigned to: Nobody (None)
Summary: [PATCH] "better" handling of with(:foo)

Initial Comment:
my_mock.should_receive(:something).with(:foo)
my_mock.something :foo
my_mock.something :bar

will blow up saying that :something was expected with :foo but received it with :bar.

In my opinion it should pass, because it was called with the supplied argument at some point.  If you want to restrict it then you should use :once.

Here's my patch (against r2831).  Let me know what you think.

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

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

From noreply at rubyforge.org  Thu Nov  8 21:47:24 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu,  8 Nov 2007 21:47:24 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-15471 ] [PATCH] &quot; better&quot;
	handling of with(:foo)
Message-ID: <20071109024724.441EE18585F0@rubyforge.org>

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

Category: mock module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Pat Maddox (pergesu)
Assigned to: Nobody (None)
>Summary: [PATCH] &quot;better&quot; handling of with(:foo)

Initial Comment:
my_mock.should_receive(:something).with(:foo)
my_mock.something :foo
my_mock.something :bar

will blow up saying that :something was expected with :foo but received it with :bar.

In my opinion it should pass, because it was called with the supplied argument at some point.  If you want to restrict it then you should use :once.

Here's my patch (against r2831).  Let me know what you think.

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

>Comment By: Pat Maddox (pergesu)
Date: 2007-11-08 19:47

Message:
btw I put "better" in quotes because judging from the
existing specs it looks like someone might disagree with me.
 So, at the very least, I'd like to generate some discussion.

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

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

From noreply at rubyforge.org  Thu Nov  8 21:59:09 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu,  8 Nov 2007 21:59:09 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-15471 ] [PATCH] &quot; better&quot;
	handling of with(:foo)
Message-ID: <20071109025909.9EC2B18586BE@rubyforge.org>

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

Category: mock module
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 3
Submitted By: Pat Maddox (pergesu)
Assigned to: Nobody (None)
Summary: [PATCH] &quot;better&quot; handling of with(:foo)

Initial Comment:
my_mock.should_receive(:something).with(:foo)
my_mock.something :foo
my_mock.something :bar

will blow up saying that :something was expected with :foo but received it with :bar.

In my opinion it should pass, because it was called with the supplied argument at some point.  If you want to restrict it then you should use :once.

Here's my patch (against r2831).  Let me know what you think.

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

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

Message:
This would not only break with tradition (most mock frameworks complain on the second, unexpected call) but it would also result in false positives in the cases in which people expect that call to complain.

I'm rejecting this, but if you want to open up a discussion about it on the list, feel free.

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

Comment By: Pat Maddox (pergesu)
Date: 2007-11-09 02:47

Message:
btw I put "better" in quotes because judging from the
existing specs it looks like someone might disagree with me.
 So, at the very least, I'd like to generate some discussion.

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

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

From tastapod at gmail.com  Fri Nov  9 11:02:30 2007
From: tastapod at gmail.com (Dan North)
Date: Fri, 9 Nov 2007 16:02:30 +0000
Subject: [rspec-devel] Story Directory Structure
In-Reply-To: <57c63afe0711081340o2ab50ebai2b070c4be6ecfaf4@mail.gmail.com>
References: <c18843c60711081158n7e4df445r955881761fb25953@mail.gmail.com>
	<57c63afe0711081229y4e1a185el8f26878aa38c0f40@mail.gmail.com>
	<c18843c60711081259o2e27edela5d27d6b7badd118@mail.gmail.com>
	<57c63afe0711081302n1fba06a8t85d93611c8c4af@mail.gmail.com>
	<c18843c60711081338u18039a34i231e72dfef09f9c2@mail.gmail.com>
	<57c63afe0711081340o2ab50ebai2b070c4be6ecfaf4@mail.gmail.com>
Message-ID: <d559d8430711090802j5b3b2c67w5a05d01345049a05@mail.gmail.com>

The rule I use is don't automate what you can't do manually. In other words,
wait until you've done enough creating and structuring stories, steps, etc.
for it to be annoying you, and then automate it :)

fwiw I've used the same structure (having scenarios and steps directories
inside a stories directory) and I really like it.

The all.rb vs finding stories argument is an interesting one. Should your
stories have to opt in to being run ( all.rb) or should any story just get
run?

One model I've seen work really well is to have two story folders, one for
in-progress stories and one for finished stories. If any stories in the done
folder fail, it breaks your build, and if any stories in the in-progress
folder *pass* it also breaks your build (because you probably ought to know
about it). With this model, you would run all the stories all the time so
you wouldn't need an all.rb file.

Cheers,
Dan

On Nov 8, 2007 9:40 PM, David Chelimsky <dchelimsky at gmail.com> wrote:

> On Nov 8, 2007 3:38 PM, Josh Knowles <joshknowles at gmail.com> wrote:
> > On 11/8/07, David Chelimsky <dchelimsky at gmail.com > wrote:
> > > There IS a rake task:
> > >
> > > rake stories
> > >
> >
> > $ rake -T | grep stories
> > $
> >
> > I must be missing something as I don't see the rake task described
> anywhere.
>
> LOL - there is in MY project - just not in the plugin! (sorry to lead
> you astray)
>
> I think it's best left that way for the time being.
>
> >
> > > However, I don't think we have enough experience/convention to know
> > > what that rake task should do - right now I get to define whatever I
> > > want in all.rb. Simpler that way, in my view.
> > >
> > > WDYT?
> >
> > Makes sense.  This allows folks to structure their stories however
> they'd like.
>
> Yes - which for the near term is a GOOD THING.
>
> Cheers,
> David
> _______________________________________________
> 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/20071109/65d69082/attachment-0001.html 

From zach.dennis at gmail.com  Fri Nov  9 22:17:50 2007
From: zach.dennis at gmail.com (Zach Dennis)
Date: Fri, 9 Nov 2007 22:17:50 -0500
Subject: [rspec-devel] Rails #8115 and spec/matchers/have
In-Reply-To: <57c63afe0711081244t286a1794q1cf45274ad75c7ab@mail.gmail.com>
References: <73460037-0E2D-44E2-9C3F-EB95CF34B93C@collectiveidea.com>
	<57c63afe0711080929t3ed44033pd09352d1e33a9994@mail.gmail.com>
	<57c63afe0711081244t286a1794q1cf45274ad75c7ab@mail.gmail.com>
Message-ID: <85d99afe0711091917w1fdc38fsa151914bd1fc2f4c@mail.gmail.com>

Rspec now breaks with Rails because of require path issues. Attached is a
patch to fix those.

It's because rspec_on_rails comes first in the $LOAD_PATH and both rspec and
rspec_on_rails now have a "extensions.rb" file so "require
'spec/extensions'" is loading the wrong one first.


-- 
Zach Dennis
http://www.continuousthinking.com

On 11/8/07, David Chelimsky <dchelimsky at gmail.com> wrote:
>
> On Nov 8, 2007 11:29 AM, David Chelimsky <dchelimsky at gmail.com> wrote:
> > On Nov 8, 2007 9:20 AM, Brandon Keepers <brandon at collectiveidea.com>
> wrote:
> > > Rails commit #8115 refactored how plugins are loaded and now adds all
> > > the vendor/plugins/*/lib directories to the load path before
> > > initializing all the plugins.
> > >
> > > rspec and rspec_on_rails both have spec/matchers/have.rb, and now that
> > > they're both in the load path, when rspec initializes and requires
> > > spec/matchers/have, the rspec_on_rails version gets loaded.
> > >
> > > This seems to only happen when I run integration tests and not specs
> > > (stack trace below).  The ways I see to fix this are 1) require these
> > > using an absolute path or 2) rename the rails one to spec/rails/
> > > matchers/have, or something along those lines.
> > >
> > > I'd be happy to submit a patch, let me know what you think about ways
> > > to get around this.
> >
> > A patch would be awesome - thanks!
> >
> > How about moving it from rspec_on_rails/lib/spec/matchers/have to
> > rspec_on_rails/lib/extensions/spec/matchers/have and include require
> > 'spec/matchers/have' from within that file.
> >
> > That file monkey patches Spec::Matchers::Have and I think putting
> > under an extensions directory makes sense.
> >
> > WDYT?
>
> Actually - I'll take care of this - should have it committed in a few.
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>



-- 
Zach Dennis
http://www.continuousthinking.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20071109/c217ab64/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rspec_require.diff
Type: application/octet-stream
Size: 1334 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/rspec-devel/attachments/20071109/c217ab64/attachment.obj 

From zach.dennis at gmail.com  Sat Nov 10 00:06:28 2007
From: zach.dennis at gmail.com (Zach Dennis)
Date: Sat, 10 Nov 2007 00:06:28 -0500
Subject: [rspec-devel] Rails #8115 and spec/matchers/have
In-Reply-To: <85d99afe0711091917w1fdc38fsa151914bd1fc2f4c@mail.gmail.com>
References: <73460037-0E2D-44E2-9C3F-EB95CF34B93C@collectiveidea.com>
	<57c63afe0711080929t3ed44033pd09352d1e33a9994@mail.gmail.com>
	<57c63afe0711081244t286a1794q1cf45274ad75c7ab@mail.gmail.com>
	<85d99afe0711091917w1fdc38fsa151914bd1fc2f4c@mail.gmail.com>
Message-ID: <85d99afe0711092106y601786d4l332ccb5b94d19db8@mail.gmail.com>

I had issues loading the story runner as well. Attached is the one line
require that fixed it...
Zach

On 11/9/07, Zach Dennis <zach.dennis at gmail.com> wrote:
>
> Rspec now breaks with Rails because of require path issues. Attached is a
> patch to fix those.
>
>
> It's because rspec_on_rails comes first in the $LOAD_PATH and both rspec
> and rspec_on_rails now have a " extensions.rb" file so "require
> 'spec/extensions'" is loading the wrong one first.
>
>
> --
> Zach Dennis
> http://www.continuousthinking.com
>
> On 11/8/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> >
> > On Nov 8, 2007 11:29 AM, David Chelimsky <dchelimsky at gmail.com> wrote:
> > > On Nov 8, 2007 9:20 AM, Brandon Keepers <brandon at collectiveidea.com >
> > wrote:
> > > > Rails commit #8115 refactored how plugins are loaded and now adds
> > all
> > > > the vendor/plugins/*/lib directories to the load path before
> > > > initializing all the plugins.
> > > >
> > > > rspec and rspec_on_rails both have spec/matchers/have.rb, and now
> > that
> > > > they're both in the load path, when rspec initializes and requires
> > > > spec/matchers/have, the rspec_on_rails version gets loaded.
> > > >
> > > > This seems to only happen when I run integration tests and not specs
> > > > (stack trace below).  The ways I see to fix this are 1) require
> > these
> > > > using an absolute path or 2) rename the rails one to spec/rails/
> > > > matchers/have, or something along those lines.
> > > >
> > > > I'd be happy to submit a patch, let me know what you think about
> > ways
> > > > to get around this.
> > >
> > > A patch would be awesome - thanks!
> > >
> > > How about moving it from rspec_on_rails/lib/spec/matchers/have to
> > > rspec_on_rails/lib/extensions/spec/matchers/have and include require
> > > 'spec/matchers/have' from within that file.
> > >
> > > That file monkey patches Spec::Matchers::Have and I think putting
> > > under an extensions directory makes sense.
> > >
> > > WDYT?
> >
> > Actually - I'll take care of this - should have it committed in a few.
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman<http://rubyforge.org/mailman/listinfo/rspec-devel>/listinfo/rspec-devel
> > <http://rubyforge.org/mailman/listinfo/rspec-devel>
> >
>
>
>
> --
> Zach Dennis
> http://www.continuousthinking <http://www.continuousthinking.com>.com<http://www.continuousthinking.com>
>
>


-- 
Zach Dennis
http://www.continuousthinking.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20071110/27033e36/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rspec_on_rails.diff
Type: application/octet-stream
Size: 342 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/rspec-devel/attachments/20071110/27033e36/attachment.obj 

From dchelimsky at gmail.com  Sat Nov 10 15:32:20 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sat, 10 Nov 2007 14:32:20 -0600
Subject: [rspec-devel] Rails #8115 and spec/matchers/have
In-Reply-To: <85d99afe0711092106y601786d4l332ccb5b94d19db8@mail.gmail.com>
References: <73460037-0E2D-44E2-9C3F-EB95CF34B93C@collectiveidea.com>
	<57c63afe0711080929t3ed44033pd09352d1e33a9994@mail.gmail.com>
	<57c63afe0711081244t286a1794q1cf45274ad75c7ab@mail.gmail.com>
	<85d99afe0711091917w1fdc38fsa151914bd1fc2f4c@mail.gmail.com>
	<85d99afe0711092106y601786d4l332ccb5b94d19db8@mail.gmail.com>
Message-ID: <57c63afe0711101232m2486232aka04e1920f9a7d993@mail.gmail.com>

On Nov 9, 2007 11:06 PM, Zach Dennis <zach.dennis at gmail.com> wrote:
> I had issues loading the story runner as well. Attached is the one line
> require that fixed it...

Hey Zach,

Thanks for the patches, but I wanted to handle things a bit
differently. I'm not a big fan of absolute paths. So I moved things
around in rspec_on_rails so there shouldn't be any collisions. This
*should* be fixed as of 2844.

Thanks,
David

>
> Zach
>
>
>
> On 11/9/07, Zach Dennis <zach.dennis at gmail.com> wrote:
> >
> > Rspec now breaks with Rails because of require path issues. Attached is a
> patch to fix those.
> >
> >
> > It's because rspec_on_rails comes first in the $LOAD_PATH and both rspec
> and rspec_on_rails now have a " extensions.rb" file so "require
> 'spec/extensions'" is loading the wrong one first.
> >
> >
> >
> > --
> > Zach Dennis
> > http://www.continuousthinking.com
> >
> >
> >
> > On 11/8/07, David Chelimsky < dchelimsky at gmail.com> wrote:
> > > On Nov 8, 2007 11:29 AM, David Chelimsky <dchelimsky at gmail.com> wrote:
> > > > On Nov 8, 2007 9:20 AM, Brandon Keepers < brandon at collectiveidea.com >
> wrote:
> > > > > Rails commit #8115 refactored how plugins are loaded and now adds
> all
> > > > > the vendor/plugins/*/lib directories to the load path before
> > > > > initializing all the plugins.
> > > > >
> > > > > rspec and rspec_on_rails both have spec/matchers/have.rb, and now
> that
> > > > > they're both in the load path, when rspec initializes and requires
> > > > > spec/matchers/have, the rspec_on_rails version gets loaded.
> > > > >
> > > > > This seems to only happen when I run integration tests and not specs
> > > > > (stack trace below).  The ways I see to fix this are 1) require
> these
> > > > > using an absolute path or 2) rename the rails one to spec/rails/
> > > > > matchers/have, or something along those lines.
> > > > >
> > > > > I'd be happy to submit a patch, let me know what you think about
> ways
> > > > > to get around this.
> > > >
> > > > A patch would be awesome - thanks!
> > > >
> > > > How about moving it from rspec_on_rails/lib/spec/matchers/have to
> > > > rspec_on_rails/lib/extensions/spec/matchers/have and include require
> > > > 'spec/matchers/have' from within that file.
> > > >
> > > > That file monkey patches Spec::Matchers::Have and I think putting
> > > > under an extensions directory makes sense.
> > > >
> > > > WDYT?
> > >
> > > Actually - I'll take care of this - should have it committed in a few.
> > > _______________________________________________
> > > rspec-devel mailing list
> > > rspec-devel at rubyforge.org
> > > http://rubyforge.org/mailman /listinfo/rspec-devel
> > >
> >
> >
> >
> > --
> > Zach Dennis
> > http://www.continuousthinking .com
> >
>
>
>
> --
>
> Zach Dennis
> http://www.continuousthinking.com
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From noreply at rubyforge.org  Sun Nov 11 03:08:33 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 11 Nov 2007 03:08:33 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15544 ] Interdependency among specs
Message-ID: <20071111080833.E32A11598067@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: Interdependency among specs

Initial Comment:

2 sets of interdependency among the specs in trunk/spec, @ revision 2848:

1. Two failures occur when running autotest (or with ruby bin/spec spec/spec/mocks/** in trunk/spec):

1)
Spec::Mocks::MockExpectationError in 'calling :should_receive with an options hash should report the file and line submitted with :expected_from'
Mock 'Spec::Runner::Reporter' expected :example_finished with (any args) once, but received it 0 times
./spec/spec/mocks/options_hash_spec.rb:21:

2)
Spec::Mocks::MockExpectationError in 'calling :should_receive with an options hash should use the message supplied with :message'
Mock 'Spec::Runner::Reporter' expected :example_finished with (any args) once, but received it 0 times
./spec/spec/mocks/options_hash_spec.rb:35:

I haven't really investigated this part of the framework - so I'll leave it up to you guys.



2. the second one can be reproduced by running the following (inside of trunk/spec):

escher: ruby bin/spec spec/spec/dsl/example_class_definition_spec.rb --reverse
F.....

1)
'Spec::DSL::ExampleClassDefinitionSpec should run' FAILED
expected true, got nil
./spec/spec/dsl/example_class_definition_spec.rb:44:

Finished in 0.00325 seconds

6 examples, 1 failure

But running them normally gives good results:

escher: ruby bin/spec spec/spec/dsl/example_class_definition_spec.rb   
......

Finished in 0.002986 seconds

6 examples, 0 failures


This second example is rather 'nitpicky' - disregard it if you don't think it's important.

Scott


BTW: I'm running on OS X.4, ruby 1.8.6 patchlevel-110, and trunk @rev 2848


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

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

From noreply at rubyforge.org  Sun Nov 11 03:58:04 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 11 Nov 2007 03:58:04 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15546 ] Rspec Build Fails
Message-ID: <20071111085804.A6C0515F8011@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: Rspec Build Fails

Initial Comment:

The rspec build is failing for me, @ revision 2848.  After the specs run (with rake spec) and all pass, I get the following error:

/usr/local/lib/ruby/1.8/rexml/text.rb:292:in `normalize': private method `gsub' called for 0:Fixnum (NoMethodError)

Attached, below, is the output:


escher: svn up; svn info; pwd; rake verify_rcov
At revision 2848.
Path: .
URL: svn://rubyforge.org/var/svn/rspec/trunk/rspec
Repository Root: svn://rubyforge.org/var/svn/rspec
Repository UUID: 410327ef-2207-0410-a325-f78bbcb22a5a
Revision: 2848
Node Kind: directory
Schedule: normal
Last Changed Author: aslak_hellesoy
Last Changed Rev: 2847
Last Changed Date: 2007-11-10 17:31:31 -0500 (Sat, 10 Nov 2007)

/Users/smt/play/rspec/rspec
(in /Users/smt/play/rspec/rspec)
Profiling enabled.
.........................................................................................................................................................................................................................P......P...........................................................................................................................P.................................................................................................................................................................................................................................................P....................................................................................................................................................................................................................................P........................................................................................................................................................................................

  Given given.
  And no match (PENDING).

  When when.
  And no match (PENDING).

  Then then.
  And no match (PENDING)...............................................................................................................................................................................


Top 10 slowest examples:
1.2913050 Translator should translate files
0.6018740 Test::Unit interaction runs tests and specs
0.6006520 Spec::Runner::CommandLine when tests are run, output test/unit sumary
0.5934550 Spec::Runner::CommandLine should not output twice
0.5880460 Test::Unit interaction monkey patches AutoRunner
0.5840390 Spec::Runner::CommandLine should not output twice
0.5830880 Spec::Runner::CommandLine when no tests are run, does not output test/unit summary
0.5290180 The bin/spec script should have no warnings
0.4790760 HtmlFormatter should produce HTML identical to the one we designed manually with --diff
0.4294800 Spec::Runner::CommandLine.run should run directory

Pending:
Object#should should raise error if it receives no argument and it is not used as a left side of an operator (Is it even possible to catch this?)
Object#should_not should raise error if it receives no argument and it is not used as a left side of an operator (Is it even possible to catch this?)
should exist, outside of a behavior should pass if target exists (need to either find a way to include stock predicate matchers in Spec::Matchers or add Bret's Exist matcher)
a Mock expectation should fail right away when method defined as never is received (Used to pass (false positive). Which one is wrong, the spec or the actual behavior?)
OptionParser should print help to stdout if no args (TODO)

Finished in 15.896248 seconds

1184 examples, 0 failures, 5 pending
/usr/local/lib/ruby/1.8/rexml/text.rb:292:in `normalize': private method `gsub' called for 0:Fixnum (NoMethodError)
        from /usr/local/lib/ruby/1.8/rexml/element.rb:1084:in `[]='
        from /usr/local/lib/ruby/1.8/rexml/element.rb:586:in `add_attribute'
        from (eval):490:in `table_'
        from (eval):490:in `each'
        from (eval):490:in `table_'
        from (eval):490:in `each'
        from (eval):490:in `table_'
        from /usr/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/lib/rcov/report.rb:702:in `format_overview'
         ... 61 levels...
        from /usr/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/lib/rcov.rb:628:in `dump_coverage_info'
        from /usr/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/lib/rcov.rb:628:in `each'
        from /usr/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/lib/rcov.rb:628:in `dump_coverage_info'
        from /usr/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/bin/rcov:405
rake aborted!
No such file or directory - ../doc/output/coverage/index.html

(See full trace by running task with --trace)




I'm running on OS X.4.10.  Here is my gem list:



escher: gem list --local

*** LOCAL GEMS ***

actionmailer (1.3.5, 1.3.3)
    Service layer for easy email delivery and testing.

actionpack (1.13.5, 1.13.3)
    Web-flow and rendering framework putting the VC in MVC.

actionwebservice (1.2.5, 1.2.3)
    Web service support for Action Pack.

activerecord (1.15.5, 1.15.3)
    Implements the ActiveRecord pattern for ORM.

activesupport (1.4.4, 1.4.2)
    Support and utility classes used by the Rails framework.

autometric (0.0.1)
    Continuously analyzes your code with rcov, saikuro, and flog

capistrano (2.1.0, 2.0.0, 1.4.1)
    Capistrano is a utility and framework for executing commands in
    parallel on multiple remote machines, via SSH.

capistrano-ext (1.2.0)
    Capistrano Extensions is a set of useful task libraries and methods
    that     other developers may reference in their own recipe files.

cgi_multipart_eof_fix (2.5.0, 2.3)
    Fix an exploitable bug in CGI multipart parsing.

cmdparse (2.0.2)
    Advanced command line parser supporting commands

daemons (1.0.9, 1.0.8)
    A toolkit to create and control daemons in different ways

deprec (1.9.0)
    deployment recipes for capistrano

diff-lcs (1.1.2)
    Provides a list of changes that represent the difference between two
    sequenced collections.

fastthread (1.0.1, 1.0)
    Optimized replacement for thread.rb primitives

gem_plugin (0.2.3, 0.2.2)
    A plugin system based on rubygems that uses dependencies only

gruff (0.2.9, 0.2.8)
    Beautiful graphs for one or multiple datasets.

heckle (1.4.1)
    Unit Test Sadism

highline (1.4.0)
    HighLine is a high-level command-line IO library.

hoe (1.3.0)
    Hoe is a way to write Rakefiles much easier and cleaner.

hpricot (0.6)
    a swift, liberal HTML parser with a fantastic library

memcache-client (1.5.0)
    A Ruby memcached client

mini_magick (1.2.3)
    A simple image manipulation library based on ImageMagick.

mongrel (1.1, 1.0.3, 1.0.2, 1.0.1)
    A small fast HTTP library and server that runs Rails, Camping, Nitro
    and Iowa apps.

mongrel_cluster (1.0.4, 1.0.3, 1.0.2)
    Mongrel plugin that provides commands and Capistrano tasks for
    managing multiple Mongrel processes.

needle (1.3.0)
    Needle is a Dependency Injection/Inversion of Control container for
    Ruby. It supports both type-2 (setter) and type-3 (constructor)
    injection. It takes advantage of the dynamic nature of Ruby to
    provide a rich and flexible approach to injecting dependencies.

net-sftp (1.1.0)
    Net::SFTP is a pure-Ruby implementation of the SFTP client protocol.

net-ssh (1.1.2)
    Net::SSH is a pure-Ruby implementation of the SSH2 client protocol.

ParseTree (2.0.2)
    ParseTree is a C extension (using RubyInline) that extracts the
    parse tree for an entire class or a specific method and returns it
    as a s-expression (aka sexp) using ruby's arrays, strings, symbols,
    and integers.

rails (1.2.5, 1.2.3)
    Web-application framework with template engine, control-flow layer,
    and ORM.

railsmachine (1.0.0, 0.1.2)
    The Rails Machine task library

rake (0.7.3)
    Ruby based make-like utility.

rcov (0.8.0.2)
    Code coverage analysis tool for Ruby

RedCloth (3.0.4)
    RedCloth is a module for using Textile and Markdown in Ruby. Textile
    and Markdown are text formats.  A very simple text format. Another
    stab at making readable text that can be converted to HTML.

rspec (1.0.8)
    RSpec-1.0.8 (r2338) - BDD for Ruby http://rspec.rubyforge.org/

ruby-debug (0.9.3)
    Command line interface (CLI) for ruby-debug-base

ruby-debug-base (0.9.3)
    Fast Ruby debugger

ruby2ruby (1.1.7)
    ruby2ruby provides a means of generating pure ruby code easily from
    ParseTree's Sexps.

rubyforge (0.4.4)
    A script which automates a limited set of rubyforge operations.

RubyInline (3.6.5, 3.6.4)
    Ruby Inline is an analog to Perl's Inline::C. Out of the box, it
    allows you to embed C/++ external module code in your ruby script
    directly.

sources (0.0.1)
    This package provides download sources for remote gem installation

sqlite3-ruby (1.2.1)
    SQLite3/Ruby is a module to allow Ruby scripts to interface with a
    SQLite3 database.

syntax (1.0.0)
    Syntax is Ruby library for performing simple syntax highlighting.

webgen (0.4.6)
    webgen is a templated based static Web site generator.

ZenTest (3.6.1)
    ZenTest provides 4 different tools and 1 library: zentest,
    unit_diff, autotest, multiruby, and Test::Rails.
escher: 




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

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

From noreply at rubyforge.org  Sun Nov 11 07:27:35 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 11 Nov 2007 07:27:35 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15546 ] Rspec Build Fails
Message-ID: <20071111122735.9BDEC185863A@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
>Priority: 2
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: Rspec Build Fails

Initial Comment:

The rspec build is failing for me, @ revision 2848.  After the specs run (with rake spec) and all pass, I get the following error:

/usr/local/lib/ruby/1.8/rexml/text.rb:292:in `normalize': private method `gsub' called for 0:Fixnum (NoMethodError)

Attached, below, is the output:


escher: svn up; svn info; pwd; rake verify_rcov
At revision 2848.
Path: .
URL: svn://rubyforge.org/var/svn/rspec/trunk/rspec
Repository Root: svn://rubyforge.org/var/svn/rspec
Repository UUID: 410327ef-2207-0410-a325-f78bbcb22a5a
Revision: 2848
Node Kind: directory
Schedule: normal
Last Changed Author: aslak_hellesoy
Last Changed Rev: 2847
Last Changed Date: 2007-11-10 17:31:31 -0500 (Sat, 10 Nov 2007)

/Users/smt/play/rspec/rspec
(in /Users/smt/play/rspec/rspec)
Profiling enabled.
.........................................................................................................................................................................................................................P......P...........................................................................................................................P.................................................................................................................................................................................................................................................P....................................................................................................................................................................................................................................P........................................................................................................................................................................................

  Given given.
  And no match (PENDING).

  When when.
  And no match (PENDING).

  Then then.
  And no match (PENDING)...............................................................................................................................................................................


Top 10 slowest examples:
1.2913050 Translator should translate files
0.6018740 Test::Unit interaction runs tests and specs
0.6006520 Spec::Runner::CommandLine when tests are run, output test/unit sumary
0.5934550 Spec::Runner::CommandLine should not output twice
0.5880460 Test::Unit interaction monkey patches AutoRunner
0.5840390 Spec::Runner::CommandLine should not output twice
0.5830880 Spec::Runner::CommandLine when no tests are run, does not output test/unit summary
0.5290180 The bin/spec script should have no warnings
0.4790760 HtmlFormatter should produce HTML identical to the one we designed manually with --diff
0.4294800 Spec::Runner::CommandLine.run should run directory

Pending:
Object#should should raise error if it receives no argument and it is not used as a left side of an operator (Is it even possible to catch this?)
Object#should_not should raise error if it receives no argument and it is not used as a left side of an operator (Is it even possible to catch this?)
should exist, outside of a behavior should pass if target exists (need to either find a way to include stock predicate matchers in Spec::Matchers or add Bret's Exist matcher)
a Mock expectation should fail right away when method defined as never is received (Used to pass (false positive). Which one is wrong, the spec or the actual behavior?)
OptionParser should print help to stdout if no args (TODO)

Finished in 15.896248 seconds

1184 examples, 0 failures, 5 pending
/usr/local/lib/ruby/1.8/rexml/text.rb:292:in `normalize': private method `gsub' called for 0:Fixnum (NoMethodError)
        from /usr/local/lib/ruby/1.8/rexml/element.rb:1084:in `[]='
        from /usr/local/lib/ruby/1.8/rexml/element.rb:586:in `add_attribute'
        from (eval):490:in `table_'
        from (eval):490:in `each'
        from (eval):490:in `table_'
        from (eval):490:in `each'
        from (eval):490:in `table_'
        from /usr/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/lib/rcov/report.rb:702:in `format_overview'
         ... 61 levels...
        from /usr/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/lib/rcov.rb:628:in `dump_coverage_info'
        from /usr/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/lib/rcov.rb:628:in `each'
        from /usr/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/lib/rcov.rb:628:in `dump_coverage_info'
        from /usr/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/bin/rcov:405
rake aborted!
No such file or directory - ../doc/output/coverage/index.html

(See full trace by running task with --trace)




I'm running on OS X.4.10.  Here is my gem list:



escher: gem list --local

*** LOCAL GEMS ***

actionmailer (1.3.5, 1.3.3)
    Service layer for easy email delivery and testing.

actionpack (1.13.5, 1.13.3)
    Web-flow and rendering framework putting the VC in MVC.

actionwebservice (1.2.5, 1.2.3)
    Web service support for Action Pack.

activerecord (1.15.5, 1.15.3)
    Implements the ActiveRecord pattern for ORM.

activesupport (1.4.4, 1.4.2)
    Support and utility classes used by the Rails framework.

autometric (0.0.1)
    Continuously analyzes your code with rcov, saikuro, and flog

capistrano (2.1.0, 2.0.0, 1.4.1)
    Capistrano is a utility and framework for executing commands in
    parallel on multiple remote machines, via SSH.

capistrano-ext (1.2.0)
    Capistrano Extensions is a set of useful task libraries and methods
    that     other developers may reference in their own recipe files.

cgi_multipart_eof_fix (2.5.0, 2.3)
    Fix an exploitable bug in CGI multipart parsing.

cmdparse (2.0.2)
    Advanced command line parser supporting commands

daemons (1.0.9, 1.0.8)
    A toolkit to create and control daemons in different ways

deprec (1.9.0)
    deployment recipes for capistrano

diff-lcs (1.1.2)
    Provides a list of changes that represent the difference between two
    sequenced collections.

fastthread (1.0.1, 1.0)
    Optimized replacement for thread.rb primitives

gem_plugin (0.2.3, 0.2.2)
    A plugin system based on rubygems that uses dependencies only

gruff (0.2.9, 0.2.8)
    Beautiful graphs for one or multiple datasets.

heckle (1.4.1)
    Unit Test Sadism

highline (1.4.0)
    HighLine is a high-level command-line IO library.

hoe (1.3.0)
    Hoe is a way to write Rakefiles much easier and cleaner.

hpricot (0.6)
    a swift, liberal HTML parser with a fantastic library

memcache-client (1.5.0)
    A Ruby memcached client

mini_magick (1.2.3)
    A simple image manipulation library based on ImageMagick.

mongrel (1.1, 1.0.3, 1.0.2, 1.0.1)
    A small fast HTTP library and server that runs Rails, Camping, Nitro
    and Iowa apps.

mongrel_cluster (1.0.4, 1.0.3, 1.0.2)
    Mongrel plugin that provides commands and Capistrano tasks for
    managing multiple Mongrel processes.

needle (1.3.0)
    Needle is a Dependency Injection/Inversion of Control container for
    Ruby. It supports both type-2 (setter) and type-3 (constructor)
    injection. It takes advantage of the dynamic nature of Ruby to
    provide a rich and flexible approach to injecting dependencies.

net-sftp (1.1.0)
    Net::SFTP is a pure-Ruby implementation of the SFTP client protocol.

net-ssh (1.1.2)
    Net::SSH is a pure-Ruby implementation of the SSH2 client protocol.

ParseTree (2.0.2)
    ParseTree is a C extension (using RubyInline) that extracts the
    parse tree for an entire class or a specific method and returns it
    as a s-expression (aka sexp) using ruby's arrays, strings, symbols,
    and integers.

rails (1.2.5, 1.2.3)
    Web-application framework with template engine, control-flow layer,
    and ORM.

railsmachine (1.0.0, 0.1.2)
    The Rails Machine task library

rake (0.7.3)
    Ruby based make-like utility.

rcov (0.8.0.2)
    Code coverage analysis tool for Ruby

RedCloth (3.0.4)
    RedCloth is a module for using Textile and Markdown in Ruby. Textile
    and Markdown are text formats.  A very simple text format. Another
    stab at making readable text that can be converted to HTML.

rspec (1.0.8)
    RSpec-1.0.8 (r2338) - BDD for Ruby http://rspec.rubyforge.org/

ruby-debug (0.9.3)
    Command line interface (CLI) for ruby-debug-base

ruby-debug-base (0.9.3)
    Fast Ruby debugger

ruby2ruby (1.1.7)
    ruby2ruby provides a means of generating pure ruby code easily from
    ParseTree's Sexps.

rubyforge (0.4.4)
    A script which automates a limited set of rubyforge operations.

RubyInline (3.6.5, 3.6.4)
    Ruby Inline is an analog to Perl's Inline::C. Out of the box, it
    allows you to embed C/++ external module code in your ruby script
    directly.

sources (0.0.1)
    This package provides download sources for remote gem installation

sqlite3-ruby (1.2.1)
    SQLite3/Ruby is a module to allow Ruby scripts to interface with a
    SQLite3 database.

syntax (1.0.0)
    Syntax is Ruby library for performing simple syntax highlighting.

webgen (0.4.6)
    webgen is a templated based static Web site generator.

ZenTest (3.6.1)
    ZenTest provides 4 different tools and 1 library: zentest,
    unit_diff, autotest, multiruby, and Test::Rails.
escher: 




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

>Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-11-11 07:27

Message:
This is RCov/REXML bugs. A little annoying, but not a big deal. I'm unable to reproduce it on my mac though.

Can you try to monkey patch REXML on the line where the error is thrown to make it work all way through?

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

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

From noreply at rubyforge.org  Sun Nov 11 08:37:32 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 11 Nov 2007 08:37:32 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15544 ] Interdependency among specs
Message-ID: <20071111133732.D156918585E8@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
>Assigned to: David Chelimsky (dchelimsky)
Summary: Interdependency among specs

Initial Comment:

2 sets of interdependency among the specs in trunk/spec, @ revision 2848:

1. Two failures occur when running autotest (or with ruby bin/spec spec/spec/mocks/** in trunk/spec):

1)
Spec::Mocks::MockExpectationError in 'calling :should_receive with an options hash should report the file and line submitted with :expected_from'
Mock 'Spec::Runner::Reporter' expected :example_finished with (any args) once, but received it 0 times
./spec/spec/mocks/options_hash_spec.rb:21:

2)
Spec::Mocks::MockExpectationError in 'calling :should_receive with an options hash should use the message supplied with :message'
Mock 'Spec::Runner::Reporter' expected :example_finished with (any args) once, but received it 0 times
./spec/spec/mocks/options_hash_spec.rb:35:

I haven't really investigated this part of the framework - so I'll leave it up to you guys.



2. the second one can be reproduced by running the following (inside of trunk/spec):

escher: ruby bin/spec spec/spec/dsl/example_class_definition_spec.rb --reverse
F.....

1)
'Spec::DSL::ExampleClassDefinitionSpec should run' FAILED
expected true, got nil
./spec/spec/dsl/example_class_definition_spec.rb:44:

Finished in 0.00325 seconds

6 examples, 1 failure

But running them normally gives good results:

escher: ruby bin/spec spec/spec/dsl/example_class_definition_spec.rb   
......

Finished in 0.002986 seconds

6 examples, 0 failures


This second example is rather 'nitpicky' - disregard it if you don't think it's important.

Scott


BTW: I'm running on OS X.4, ruby 1.8.6 patchlevel-110, and trunk @rev 2848


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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-11 13:37

Message:
Got options_hash_spec working with or without --reverse. Don't understand the dependency yet.

Also still need to figure out the 2nd one.

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

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

From zach.dennis at gmail.com  Sun Nov 11 11:38:00 2007
From: zach.dennis at gmail.com (Zach Dennis)
Date: Sun, 11 Nov 2007 11:38:00 -0500
Subject: [rspec-devel] Rails #8115 and spec/matchers/have
In-Reply-To: <57c63afe0711101232m2486232aka04e1920f9a7d993@mail.gmail.com>
References: <73460037-0E2D-44E2-9C3F-EB95CF34B93C@collectiveidea.com>
	<57c63afe0711080929t3ed44033pd09352d1e33a9994@mail.gmail.com>
	<57c63afe0711081244t286a1794q1cf45274ad75c7ab@mail.gmail.com>
	<85d99afe0711091917w1fdc38fsa151914bd1fc2f4c@mail.gmail.com>
	<85d99afe0711092106y601786d4l332ccb5b94d19db8@mail.gmail.com>
	<57c63afe0711101232m2486232aka04e1920f9a7d993@mail.gmail.com>
Message-ID: <85d99afe0711110838s440d0d22o11625677a92d5b7b@mail.gmail.com>

This fixes it. Thanks for jumping on it!

-- 
Zach Dennis
http://www.continuousthinking.com



On Nov 10, 2007 3:32 PM, David Chelimsky <dchelimsky at gmail.com> wrote:

> On Nov 9, 2007 11:06 PM, Zach Dennis <zach.dennis at gmail.com> wrote:
> > I had issues loading the story runner as well. Attached is the one line
> > require that fixed it...
>
> Hey Zach,
>
> Thanks for the patches, but I wanted to handle things a bit
> differently. I'm not a big fan of absolute paths. So I moved things
> around in rspec_on_rails so there shouldn't be any collisions. This
> *should* be fixed as of 2844.
>
> Thanks,
> David
>
> >
> > Zach
> >
> >
> >
> > On 11/9/07, Zach Dennis <zach.dennis at gmail.com> wrote:
> > >
> > > Rspec now breaks with Rails because of require path issues. Attached
> is a
> > patch to fix those.
> > >
> > >
> > > It's because rspec_on_rails comes first in the $LOAD_PATH and both
> rspec
> > and rspec_on_rails now have a " extensions.rb" file so "require
> > 'spec/extensions'" is loading the wrong one first.
> > >
> > >
> > >
> > > --
> > > Zach Dennis
> > > http://www.continuousthinking.com
> > >
> > >
> > >
> > > On 11/8/07, David Chelimsky < dchelimsky at gmail.com> wrote:
> > > > On Nov 8, 2007 11:29 AM, David Chelimsky <dchelimsky at gmail.com>
> wrote:
> > > > > On Nov 8, 2007 9:20 AM, Brandon Keepers <
> brandon at collectiveidea.com >
> > wrote:
> > > > > > Rails commit #8115 refactored how plugins are loaded and now
> adds
> > all
> > > > > > the vendor/plugins/*/lib directories to the load path before
> > > > > > initializing all the plugins.
> > > > > >
> > > > > > rspec and rspec_on_rails both have spec/matchers/have.rb, and
> now
> > that
> > > > > > they're both in the load path, when rspec initializes and
> requires
> > > > > > spec/matchers/have, the rspec_on_rails version gets loaded.
> > > > > >
> > > > > > This seems to only happen when I run integration tests and not
> specs
> > > > > > (stack trace below).  The ways I see to fix this are 1) require
> > these
> > > > > > using an absolute path or 2) rename the rails one to spec/rails/
> > > > > > matchers/have, or something along those lines.
> > > > > >
> > > > > > I'd be happy to submit a patch, let me know what you think about
> > ways
> > > > > > to get around this.
> > > > >
> > > > > A patch would be awesome - thanks!
> > > > >
> > > > > How about moving it from rspec_on_rails/lib/spec/matchers/have to
> > > > > rspec_on_rails/lib/extensions/spec/matchers/have and include
> require
> > > > > 'spec/matchers/have' from within that file.
> > > > >
> > > > > That file monkey patches Spec::Matchers::Have and I think putting
> > > > > under an extensions directory makes sense.
> > > > >
> > > > > WDYT?
> > > >
> > > > Actually - I'll take care of this - should have it committed in a
> few.
> > > > _______________________________________________
> > > > rspec-devel mailing list
> > > > rspec-devel at rubyforge.org
> > > > http://rubyforge.org/mailman /listinfo/rspec-devel
> > > >
> > >
> > >
> > >
> > > --
> > > Zach Dennis
> > > http://www.continuousthinking .com
> > >
> >
> >
> >
> > --
> >
> > Zach Dennis
> > http://www.continuousthinking.com
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
>



-- 
Zach Dennis
http://www.continuousthinking.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20071111/063cb655/attachment.html 

From noreply at rubyforge.org  Sun Nov 11 16:39:24 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 11 Nov 2007 16:39:24 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15544 ] Interdependency among specs
Message-ID: <20071111213924.E13AF1598078@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: David Chelimsky (dchelimsky)
Summary: Interdependency among specs

Initial Comment:

2 sets of interdependency among the specs in trunk/spec, @ revision 2848:

1. Two failures occur when running autotest (or with ruby bin/spec spec/spec/mocks/** in trunk/spec):

1)
Spec::Mocks::MockExpectationError in 'calling :should_receive with an options hash should report the file and line submitted with :expected_from'
Mock 'Spec::Runner::Reporter' expected :example_finished with (any args) once, but received it 0 times
./spec/spec/mocks/options_hash_spec.rb:21:

2)
Spec::Mocks::MockExpectationError in 'calling :should_receive with an options hash should use the message supplied with :message'
Mock 'Spec::Runner::Reporter' expected :example_finished with (any args) once, but received it 0 times
./spec/spec/mocks/options_hash_spec.rb:35:

I haven't really investigated this part of the framework - so I'll leave it up to you guys.



2. the second one can be reproduced by running the following (inside of trunk/spec):

escher: ruby bin/spec spec/spec/dsl/example_class_definition_spec.rb --reverse
F.....

1)
'Spec::DSL::ExampleClassDefinitionSpec should run' FAILED
expected true, got nil
./spec/spec/dsl/example_class_definition_spec.rb:44:

Finished in 0.00325 seconds

6 examples, 1 failure

But running them normally gives good results:

escher: ruby bin/spec spec/spec/dsl/example_class_definition_spec.rb   
......

Finished in 0.002986 seconds

6 examples, 0 failures


This second example is rather 'nitpicky' - disregard it if you don't think it's important.

Scott


BTW: I'm running on OS X.4, ruby 1.8.6 patchlevel-110, and trunk @rev 2848


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

>Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-11-11 21:39

Message:
The second one occurs because the specs look like this:


module MyMod
  class SomeClass
    
    it "should run this spec" do
      run_this = true
    end
  end
  
  describe "SomeClass" do
    it "should run the spec" do
      run_this.should be_true
    end
  end
end

When the specs are run (forward), run_this gets set to true,
and the second spec passes.  When run backwards, run_this
only gets set to true in the second spec, failing the first one.

Obviously I haven't presented the details of this right -
the variable is well scoped (meaning it won't go out of
scope as it would in this example).

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-11 13:37

Message:
Got options_hash_spec working with or without --reverse. Don't understand the dependency yet.

Also still need to figure out the 2nd one.

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

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

From aslak.hellesoy at gmail.com  Sun Nov 11 18:39:06 2007
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Mon, 12 Nov 2007 00:39:06 +0100
Subject: [rspec-devel] Who's using --format rdoc
Message-ID: <8d961d900711111539l7bdd1433h2492287839f3e92a@mail.gmail.com>

I'm doing some housekeeping and just realised that the rdoc formatter
produces gibberish:
http://rspec.rubyforge.org/rdoc/files/EXAMPLES_rd.html

Will anyone protest if I just go ahead and remove it? (I can't imagine
anyone using it, especially with the much better HTML formatter)

Aslak

From noreply at rubyforge.org  Sun Nov 11 19:01:15 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 11 Nov 2007 19:01:15 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15546 ] Rspec Build Fails
Message-ID: <20071112000115.9759F185864F@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 2
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: Rspec Build Fails

Initial Comment:

The rspec build is failing for me, @ revision 2848.  After the specs run (with rake spec) and all pass, I get the following error:

/usr/local/lib/ruby/1.8/rexml/text.rb:292:in `normalize': private method `gsub' called for 0:Fixnum (NoMethodError)

Attached, below, is the output:


escher: svn up; svn info; pwd; rake verify_rcov
At revision 2848.
Path: .
URL: svn://rubyforge.org/var/svn/rspec/trunk/rspec
Repository Root: svn://rubyforge.org/var/svn/rspec
Repository UUID: 410327ef-2207-0410-a325-f78bbcb22a5a
Revision: 2848
Node Kind: directory
Schedule: normal
Last Changed Author: aslak_hellesoy
Last Changed Rev: 2847
Last Changed Date: 2007-11-10 17:31:31 -0500 (Sat, 10 Nov 2007)

/Users/smt/play/rspec/rspec
(in /Users/smt/play/rspec/rspec)
Profiling enabled.
.........................................................................................................................................................................................................................P......P...........................................................................................................................P.................................................................................................................................................................................................................................................P....................................................................................................................................................................................................................................P........................................................................................................................................................................................

  Given given.
  And no match (PENDING).

  When when.
  And no match (PENDING).

  Then then.
  And no match (PENDING)...............................................................................................................................................................................


Top 10 slowest examples:
1.2913050 Translator should translate files
0.6018740 Test::Unit interaction runs tests and specs
0.6006520 Spec::Runner::CommandLine when tests are run, output test/unit sumary
0.5934550 Spec::Runner::CommandLine should not output twice
0.5880460 Test::Unit interaction monkey patches AutoRunner
0.5840390 Spec::Runner::CommandLine should not output twice
0.5830880 Spec::Runner::CommandLine when no tests are run, does not output test/unit summary
0.5290180 The bin/spec script should have no warnings
0.4790760 HtmlFormatter should produce HTML identical to the one we designed manually with --diff
0.4294800 Spec::Runner::CommandLine.run should run directory

Pending:
Object#should should raise error if it receives no argument and it is not used as a left side of an operator (Is it even possible to catch this?)
Object#should_not should raise error if it receives no argument and it is not used as a left side of an operator (Is it even possible to catch this?)
should exist, outside of a behavior should pass if target exists (need to either find a way to include stock predicate matchers in Spec::Matchers or add Bret's Exist matcher)
a Mock expectation should fail right away when method defined as never is received (Used to pass (false positive). Which one is wrong, the spec or the actual behavior?)
OptionParser should print help to stdout if no args (TODO)

Finished in 15.896248 seconds

1184 examples, 0 failures, 5 pending
/usr/local/lib/ruby/1.8/rexml/text.rb:292:in `normalize': private method `gsub' called for 0:Fixnum (NoMethodError)
        from /usr/local/lib/ruby/1.8/rexml/element.rb:1084:in `[]='
        from /usr/local/lib/ruby/1.8/rexml/element.rb:586:in `add_attribute'
        from (eval):490:in `table_'
        from (eval):490:in `each'
        from (eval):490:in `table_'
        from (eval):490:in `each'
        from (eval):490:in `table_'
        from /usr/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/lib/rcov/report.rb:702:in `format_overview'
         ... 61 levels...
        from /usr/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/lib/rcov.rb:628:in `dump_coverage_info'
        from /usr/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/lib/rcov.rb:628:in `each'
        from /usr/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/lib/rcov.rb:628:in `dump_coverage_info'
        from /usr/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/bin/rcov:405
rake aborted!
No such file or directory - ../doc/output/coverage/index.html

(See full trace by running task with --trace)




I'm running on OS X.4.10.  Here is my gem list:



escher: gem list --local

*** LOCAL GEMS ***

actionmailer (1.3.5, 1.3.3)
    Service layer for easy email delivery and testing.

actionpack (1.13.5, 1.13.3)
    Web-flow and rendering framework putting the VC in MVC.

actionwebservice (1.2.5, 1.2.3)
    Web service support for Action Pack.

activerecord (1.15.5, 1.15.3)
    Implements the ActiveRecord pattern for ORM.

activesupport (1.4.4, 1.4.2)
    Support and utility classes used by the Rails framework.

autometric (0.0.1)
    Continuously analyzes your code with rcov, saikuro, and flog

capistrano (2.1.0, 2.0.0, 1.4.1)
    Capistrano is a utility and framework for executing commands in
    parallel on multiple remote machines, via SSH.

capistrano-ext (1.2.0)
    Capistrano Extensions is a set of useful task libraries and methods
    that     other developers may reference in their own recipe files.

cgi_multipart_eof_fix (2.5.0, 2.3)
    Fix an exploitable bug in CGI multipart parsing.

cmdparse (2.0.2)
    Advanced command line parser supporting commands

daemons (1.0.9, 1.0.8)
    A toolkit to create and control daemons in different ways

deprec (1.9.0)
    deployment recipes for capistrano

diff-lcs (1.1.2)
    Provides a list of changes that represent the difference between two
    sequenced collections.

fastthread (1.0.1, 1.0)
    Optimized replacement for thread.rb primitives

gem_plugin (0.2.3, 0.2.2)
    A plugin system based on rubygems that uses dependencies only

gruff (0.2.9, 0.2.8)
    Beautiful graphs for one or multiple datasets.

heckle (1.4.1)
    Unit Test Sadism

highline (1.4.0)
    HighLine is a high-level command-line IO library.

hoe (1.3.0)
    Hoe is a way to write Rakefiles much easier and cleaner.

hpricot (0.6)
    a swift, liberal HTML parser with a fantastic library

memcache-client (1.5.0)
    A Ruby memcached client

mini_magick (1.2.3)
    A simple image manipulation library based on ImageMagick.

mongrel (1.1, 1.0.3, 1.0.2, 1.0.1)
    A small fast HTTP library and server that runs Rails, Camping, Nitro
    and Iowa apps.

mongrel_cluster (1.0.4, 1.0.3, 1.0.2)
    Mongrel plugin that provides commands and Capistrano tasks for
    managing multiple Mongrel processes.

needle (1.3.0)
    Needle is a Dependency Injection/Inversion of Control container for
    Ruby. It supports both type-2 (setter) and type-3 (constructor)
    injection. It takes advantage of the dynamic nature of Ruby to
    provide a rich and flexible approach to injecting dependencies.

net-sftp (1.1.0)
    Net::SFTP is a pure-Ruby implementation of the SFTP client protocol.

net-ssh (1.1.2)
    Net::SSH is a pure-Ruby implementation of the SSH2 client protocol.

ParseTree (2.0.2)
    ParseTree is a C extension (using RubyInline) that extracts the
    parse tree for an entire class or a specific method and returns it
    as a s-expression (aka sexp) using ruby's arrays, strings, symbols,
    and integers.

rails (1.2.5, 1.2.3)
    Web-application framework with template engine, control-flow layer,
    and ORM.

railsmachine (1.0.0, 0.1.2)
    The Rails Machine task library

rake (0.7.3)
    Ruby based make-like utility.

rcov (0.8.0.2)
    Code coverage analysis tool for Ruby

RedCloth (3.0.4)
    RedCloth is a module for using Textile and Markdown in Ruby. Textile
    and Markdown are text formats.  A very simple text format. Another
    stab at making readable text that can be converted to HTML.

rspec (1.0.8)
    RSpec-1.0.8 (r2338) - BDD for Ruby http://rspec.rubyforge.org/

ruby-debug (0.9.3)
    Command line interface (CLI) for ruby-debug-base

ruby-debug-base (0.9.3)
    Fast Ruby debugger

ruby2ruby (1.1.7)
    ruby2ruby provides a means of generating pure ruby code easily from
    ParseTree's Sexps.

rubyforge (0.4.4)
    A script which automates a limited set of rubyforge operations.

RubyInline (3.6.5, 3.6.4)
    Ruby Inline is an analog to Perl's Inline::C. Out of the box, it
    allows you to embed C/++ external module code in your ruby script
    directly.

sources (0.0.1)
    This package provides download sources for remote gem installation

sqlite3-ruby (1.2.1)
    SQLite3/Ruby is a module to allow Ruby scripts to interface with a
    SQLite3 database.

syntax (1.0.0)
    Syntax is Ruby library for performing simple syntax highlighting.

webgen (0.4.6)
    webgen is a templated based static Web site generator.

ZenTest (3.6.1)
    ZenTest provides 4 different tools and 1 library: zentest,
    unit_diff, autotest, multiruby, and Test::Rails.
escher: 




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

>Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-11-12 00:01

Message:
Tried to monkey patch it, but didn't get far (didn't get it
to work).  

Anyway - I've got a patch thats ready to go.  I know that
rspec's internals are changing pretty rapidly, so I'd like
to get this into rspec core sooner rather than later.  

Would it be ok to send you the patch before pre_commit?  Or
maybe you could tell me what version of rcov & rexml you are
using?

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-11-11 12:27

Message:
This is RCov/REXML bugs. A little annoying, but not a big deal. I'm unable to reproduce it on my mac though.

Can you try to monkey patch REXML on the line where the error is thrown to make it work all way through?

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

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

From mailing_lists at railsnewbie.com  Sun Nov 11 18:46:58 2007
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Sun, 11 Nov 2007 18:46:58 -0500
Subject: [rspec-devel] Who's using --format rdoc
In-Reply-To: <8d961d900711111539l7bdd1433h2492287839f3e92a@mail.gmail.com>
References: <8d961d900711111539l7bdd1433h2492287839f3e92a@mail.gmail.com>
Message-ID: <8DEA20FB-7C69-4208-B8E8-85120E461D54@railsnewbie.com>


On Nov 11, 2007, at 6:39 PM, aslak hellesoy wrote:

> I'm doing some housekeeping and just realised that the rdoc formatter
> produces gibberish:
> http://rspec.rubyforge.org/rdoc/files/EXAMPLES_rd.html
>
> Will anyone protest if I just go ahead and remove it? (I can't imagine
> anyone using it, especially with the much better HTML formatter)
>

I'm not even sure what --format rdoc even does... What is it supposed  
to do?

Scott




From noreply at rubyforge.org  Sun Nov 11 22:23:26 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 11 Nov 2007 22:23:26 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-15471 ] [PATCH] &amp; quot; better&amp;
	quot; handling of with(:foo)
Message-ID: <20071112032326.E6EC0185863B@rubyforge.org>

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

Category: mock module
Group: None
Status: Closed
Resolution: Rejected
Priority: 3
Submitted By: Pat Maddox (pergesu)
Assigned to: Nobody (None)
>Summary: [PATCH] &amp;quot;better&amp;quot; handling of with(:foo)

Initial Comment:
my_mock.should_receive(:something).with(:foo)
my_mock.something :foo
my_mock.something :bar

will blow up saying that :something was expected with :foo but received it with :bar.

In my opinion it should pass, because it was called with the supplied argument at some point.  If you want to restrict it then you should use :once.

Here's my patch (against r2831).  Let me know what you think.

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

>Comment By: Pat Maddox (pergesu)
Date: 2007-11-11 20:23

Message:
I'm pretty certain this just came from a brain fart.  Of
course if you want to swallow calls then you should just
stub the method, and then you can expect a call as well.  I
agree that the mock object should be kept very tight unless
explicitly configured otherwise.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-08 19:59

Message:
This would not only break with tradition (most mock frameworks complain on the second, unexpected call) but it would also result in false positives in the cases in which people expect that call to complain.

I'm rejecting this, but if you want to open up a discussion about it on the list, feel free.

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

Comment By: Pat Maddox (pergesu)
Date: 2007-11-08 19:47

Message:
btw I put "better" in quotes because judging from the
existing specs it looks like someone might disagree with me.
 So, at the very least, I'd like to generate some discussion.

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

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

From noreply at rubyforge.org  Sun Nov 11 22:52:33 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 11 Nov 2007 22:52:33 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-15565 ] [PATCH] Adding support for
	by_at_least/by_at_most in Change matcher.
Message-ID: <20071112035233.D5AD41598078@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Saimon Moore (saimon)
Assigned to: Nobody (None)
Summary: [PATCH] Adding support for by_at_least/by_at_most in Change matcher. 

Initial Comment:
Added the following methods to Spec::Matchers:Change

def by_at_least(minimum);...end 

def by_at_most(maximum);...end

Example specs:

  it "should pass when attribute is changed by greater than the expected amount" do
    lambda { @instance.some_value += 2 }.should change(@instance, :some_value).by_at_least(1)
  end

  it "should pass when attribute is changed by less than the expected amount" do
    lambda { @instance.some_value += 2 }.should change(@instance, :some_value).by_at_most(3)
  end

Patch has full specs and updated documentation.


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

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

From lists-rspec at shopwatch.org  Mon Nov 12 09:59:44 2007
From: lists-rspec at shopwatch.org (Jay Levitt)
Date: Mon, 12 Nov 2007 09:59:44 -0500
Subject: [rspec-devel] Dev Process (was Am I missing something with
	Heckle?)
In-Reply-To: <57c63afe0710310807l9c69031neb12d6dfaa0692@mail.gmail.com>
References: <57c63afe0710310807l9c69031neb12d6dfaa0692@mail.gmail.com>
Message-ID: <47386A60.1060707@shopwatch.org>

On 10/31/2007 11:07 AM, David Chelimsky wrote:
> On Oct 31, 2007 9:56 AM, Wincent Colaiuta <win at wincent.com> wrote:
>> If the suckiness of Subversion's merge functionality is a problem then
>> RSpec should consider moving to a different SCM, or at least layering
>> one on top of the existing Subversion repo (ie. "the" Subversion repo
>> continues to be the centralized distribution point, but the devs do
>> the "real work" using Git).
> 
> We've been thinking of mercurial actually.

A little late for a response, but:

As cool as mercurial may be, you might want to see how you like SVN 
1.5's merge features.  It's only a starting point, and some things were 
already possible with svnmerge.py, but now it's in core, and it's much 
more solid and extensible.  Cherry-picking is supported out of the gate, 
and there's already a pretty cool graphical merge client from CollabNet.

I've got nothing against mercurial; I don't know much about it, other 
than that Adium just switched to it and I keep seeing posts on their 
blog about "hg is great, no more subversion limitations, now all I had 
to do is set up a cgi server on my Mac so other people can get my 
changes and then push fewer than 100 revisions at a time to avoid the 
broken-pipe bug and then I switched to ssh and ran out of disk space and 
OBTW, this won't really work well for testers who aren't contributors 
because downloading the full history takes an hour".  OK, maybe I have a 
little against Mercurial.

But mostly I'm noticing in the past few months that people are 
all-of-a-sudden switching away from Subversion, just when it's finally 
getting past its "first make everything in cvs work properly" stage.  As 
someone who uses an IDE, I find dealing with multiple SCMs is a real 
pain, and one of the cool things about Ruby has been that 
(traditionally) nearly everything's in Subversion.

If you just want easier merges, 1.5 may solve things.  If you really 
want distributed SCM, something simple like svk-over-svn may do it, but 
I honestly think that's overkill for a relatively compact project like 
RSpec with a small core team.  We just need branches and better merging.

See: http://merge-tracking.open.collab.net/


From noreply at rubyforge.org  Mon Nov 12 11:40:48 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 12 Nov 2007 11:40:48 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15546 ] Rspec Build Fails
Message-ID: <20071112164048.C08171858632@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 2
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: Rspec Build Fails

Initial Comment:

The rspec build is failing for me, @ revision 2848.  After the specs run (with rake spec) and all pass, I get the following error:

/usr/local/lib/ruby/1.8/rexml/text.rb:292:in `normalize': private method `gsub' called for 0:Fixnum (NoMethodError)

Attached, below, is the output:


escher: svn up; svn info; pwd; rake verify_rcov
At revision 2848.
Path: .
URL: svn://rubyforge.org/var/svn/rspec/trunk/rspec
Repository Root: svn://rubyforge.org/var/svn/rspec
Repository UUID: 410327ef-2207-0410-a325-f78bbcb22a5a
Revision: 2848
Node Kind: directory
Schedule: normal
Last Changed Author: aslak_hellesoy
Last Changed Rev: 2847
Last Changed Date: 2007-11-10 17:31:31 -0500 (Sat, 10 Nov 2007)

/Users/smt/play/rspec/rspec
(in /Users/smt/play/rspec/rspec)
Profiling enabled.
.........................................................................................................................................................................................................................P......P...........................................................................................................................P.................................................................................................................................................................................................................................................P....................................................................................................................................................................................................................................P........................................................................................................................................................................................

  Given given.
  And no match (PENDING).

  When when.
  And no match (PENDING).

  Then then.
  And no match (PENDING)...............................................................................................................................................................................


Top 10 slowest examples:
1.2913050 Translator should translate files
0.6018740 Test::Unit interaction runs tests and specs
0.6006520 Spec::Runner::CommandLine when tests are run, output test/unit sumary
0.5934550 Spec::Runner::CommandLine should not output twice
0.5880460 Test::Unit interaction monkey patches AutoRunner
0.5840390 Spec::Runner::CommandLine should not output twice
0.5830880 Spec::Runner::CommandLine when no tests are run, does not output test/unit summary
0.5290180 The bin/spec script should have no warnings
0.4790760 HtmlFormatter should produce HTML identical to the one we designed manually with --diff
0.4294800 Spec::Runner::CommandLine.run should run directory

Pending:
Object#should should raise error if it receives no argument and it is not used as a left side of an operator (Is it even possible to catch this?)
Object#should_not should raise error if it receives no argument and it is not used as a left side of an operator (Is it even possible to catch this?)
should exist, outside of a behavior should pass if target exists (need to either find a way to include stock predicate matchers in Spec::Matchers or add Bret's Exist matcher)
a Mock expectation should fail right away when method defined as never is received (Used to pass (false positive). Which one is wrong, the spec or the actual behavior?)
OptionParser should print help to stdout if no args (TODO)

Finished in 15.896248 seconds

1184 examples, 0 failures, 5 pending
/usr/local/lib/ruby/1.8/rexml/text.rb:292:in `normalize': private method `gsub' called for 0:Fixnum (NoMethodError)
        from /usr/local/lib/ruby/1.8/rexml/element.rb:1084:in `[]='
        from /usr/local/lib/ruby/1.8/rexml/element.rb:586:in `add_attribute'
        from (eval):490:in `table_'
        from (eval):490:in `each'
        from (eval):490:in `table_'
        from (eval):490:in `each'
        from (eval):490:in `table_'
        from /usr/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/lib/rcov/report.rb:702:in `format_overview'
         ... 61 levels...
        from /usr/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/lib/rcov.rb:628:in `dump_coverage_info'
        from /usr/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/lib/rcov.rb:628:in `each'
        from /usr/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/lib/rcov.rb:628:in `dump_coverage_info'
        from /usr/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/bin/rcov:405
rake aborted!
No such file or directory - ../doc/output/coverage/index.html

(See full trace by running task with --trace)




I'm running on OS X.4.10.  Here is my gem list:



escher: gem list --local

*** LOCAL GEMS ***

actionmailer (1.3.5, 1.3.3)
    Service layer for easy email delivery and testing.

actionpack (1.13.5, 1.13.3)
    Web-flow and rendering framework putting the VC in MVC.

actionwebservice (1.2.5, 1.2.3)
    Web service support for Action Pack.

activerecord (1.15.5, 1.15.3)
    Implements the ActiveRecord pattern for ORM.

activesupport (1.4.4, 1.4.2)
    Support and utility classes used by the Rails framework.

autometric (0.0.1)
    Continuously analyzes your code with rcov, saikuro, and flog

capistrano (2.1.0, 2.0.0, 1.4.1)
    Capistrano is a utility and framework for executing commands in
    parallel on multiple remote machines, via SSH.

capistrano-ext (1.2.0)
    Capistrano Extensions is a set of useful task libraries and methods
    that     other developers may reference in their own recipe files.

cgi_multipart_eof_fix (2.5.0, 2.3)
    Fix an exploitable bug in CGI multipart parsing.

cmdparse (2.0.2)
    Advanced command line parser supporting commands

daemons (1.0.9, 1.0.8)
    A toolkit to create and control daemons in different ways

deprec (1.9.0)
    deployment recipes for capistrano

diff-lcs (1.1.2)
    Provides a list of changes that represent the difference between two
    sequenced collections.

fastthread (1.0.1, 1.0)
    Optimized replacement for thread.rb primitives

gem_plugin (0.2.3, 0.2.2)
    A plugin system based on rubygems that uses dependencies only

gruff (0.2.9, 0.2.8)
    Beautiful graphs for one or multiple datasets.

heckle (1.4.1)
    Unit Test Sadism

highline (1.4.0)
    HighLine is a high-level command-line IO library.

hoe (1.3.0)
    Hoe is a way to write Rakefiles much easier and cleaner.

hpricot (0.6)
    a swift, liberal HTML parser with a fantastic library

memcache-client (1.5.0)
    A Ruby memcached client

mini_magick (1.2.3)
    A simple image manipulation library based on ImageMagick.

mongrel (1.1, 1.0.3, 1.0.2, 1.0.1)
    A small fast HTTP library and server that runs Rails, Camping, Nitro
    and Iowa apps.

mongrel_cluster (1.0.4, 1.0.3, 1.0.2)
    Mongrel plugin that provides commands and Capistrano tasks for
    managing multiple Mongrel processes.

needle (1.3.0)
    Needle is a Dependency Injection/Inversion of Control container for
    Ruby. It supports both type-2 (setter) and type-3 (constructor)
    injection. It takes advantage of the dynamic nature of Ruby to
    provide a rich and flexible approach to injecting dependencies.

net-sftp (1.1.0)
    Net::SFTP is a pure-Ruby implementation of the SFTP client protocol.

net-ssh (1.1.2)
    Net::SSH is a pure-Ruby implementation of the SSH2 client protocol.

ParseTree (2.0.2)
    ParseTree is a C extension (using RubyInline) that extracts the
    parse tree for an entire class or a specific method and returns it
    as a s-expression (aka sexp) using ruby's arrays, strings, symbols,
    and integers.

rails (1.2.5, 1.2.3)
    Web-application framework with template engine, control-flow layer,
    and ORM.

railsmachine (1.0.0, 0.1.2)
    The Rails Machine task library

rake (0.7.3)
    Ruby based make-like utility.

rcov (0.8.0.2)
    Code coverage analysis tool for Ruby

RedCloth (3.0.4)
    RedCloth is a module for using Textile and Markdown in Ruby. Textile
    and Markdown are text formats.  A very simple text format. Another
    stab at making readable text that can be converted to HTML.

rspec (1.0.8)
    RSpec-1.0.8 (r2338) - BDD for Ruby http://rspec.rubyforge.org/

ruby-debug (0.9.3)
    Command line interface (CLI) for ruby-debug-base

ruby-debug-base (0.9.3)
    Fast Ruby debugger

ruby2ruby (1.1.7)
    ruby2ruby provides a means of generating pure ruby code easily from
    ParseTree's Sexps.

rubyforge (0.4.4)
    A script which automates a limited set of rubyforge operations.

RubyInline (3.6.5, 3.6.4)
    Ruby Inline is an analog to Perl's Inline::C. Out of the box, it
    allows you to embed C/++ external module code in your ruby script
    directly.

sources (0.0.1)
    This package provides download sources for remote gem installation

sqlite3-ruby (1.2.1)
    SQLite3/Ruby is a module to allow Ruby scripts to interface with a
    SQLite3 database.

syntax (1.0.0)
    Syntax is Ruby library for performing simple syntax highlighting.

webgen (0.4.6)
    webgen is a templated based static Web site generator.

ZenTest (3.6.1)
    ZenTest provides 4 different tools and 1 library: zentest,
    unit_diff, autotest, multiruby, and Test::Rails.
escher: 




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

>Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-11-12 16:40

Message:
No longer having this problem at revision 2879.  You can
close this ticket (thanks if you've fixed it).

Scott


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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-11-12 00:01

Message:
Tried to monkey patch it, but didn't get far (didn't get it
to work).  

Anyway - I've got a patch thats ready to go.  I know that
rspec's internals are changing pretty rapidly, so I'd like
to get this into rspec core sooner rather than later.  

Would it be ok to send you the patch before pre_commit?  Or
maybe you could tell me what version of rcov & rexml you are
using?

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-11-11 12:27

Message:
This is RCov/REXML bugs. A little annoying, but not a big deal. I'm unable to reproduce it on my mac though.

Can you try to monkey patch REXML on the line where the error is thrown to make it work all way through?

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

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

From noreply at rubyforge.org  Mon Nov 12 11:44:12 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 12 Nov 2007 11:44:12 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15584 ] Rspec Build Fails with rails
	1.2.4
Message-ID: <20071112164412.72016185863A@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: Rspec Build Fails with rails 1.2.4

Initial Comment:

With a brand new trunk with no changes (at revision 2879), rake pre_commit fails when building rails 1.2.4.  Here is the error message that I'm getting (with  cd example_rails_app/; rake -f Multirails.rake pre_commit --trace):

#####################################################
running pre_commit against rails 1.2.4
#####################################################
#####################################################
Removing generated files:
#####################################################
#####################################################
Migrating down and reverting config/routes.rb
#####################################################
rake aborted!
no such file to load -- /Users/smt/play/rspec/example_rails_app/vendor/rails/1.2.4/railties/lib/initializer
/usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require'
/usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'
/Users/smt/play/rspec/example_rails_app/config/boot.rb:27
/usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require'
/usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'
/Users/smt/play/rspec/example_rails_app/rakefile:4
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1940:in `load'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1940:in `raw_load_rakefile'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1727:in `load_rakefile'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1761:in `standard_exception_handling'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1726:in `load_rakefile'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1710:in `run'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1761:in `standard_exception_handling'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1708:in `run'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/bin/rake:7
/usr/local/bin/rake:16:in `load'
/usr/local/bin/rake:16
(in /Users/smt/play/rspec/example_rails_app)
running against rails 1.2.4
rake aborted!
ERROR while running rake: rake db:migrate VERSION=4 --trace
/Users/smt/play/rspec/pre_commit/lib/pre_commit/pre_commit.rb:19:in `rake_sh'
/Users/smt/play/rspec/pre_commit/lib/pre_commit/rspec_on_rails.rb:169:in `migrate_down'
/Users/smt/play/rspec/pre_commit/lib/pre_commit/rspec_on_rails.rb:158:in `destroy_purchase'
/Users/smt/play/rspec/pre_commit/lib/pre_commit/rspec_on_rails.rb:49:in `cleanup'
/Users/smt/play/rspec/pre_commit/lib/pre_commit/rspec_on_rails.rb:32:in `rspec_pre_commit'
/Users/smt/play/rspec/pre_commit/lib/pre_commit/rspec_on_rails.rb:9:in `pre_commit'
/Users/smt/play/rspec/pre_commit/lib/pre_commit/rspec_on_rails.rb:6:in `each'
/Users/smt/play/rspec/pre_commit/lib/pre_commit/rspec_on_rails.rb:6:in `pre_commit'
/Users/smt/play/rspec/example_rails_app/Multirails.rake:7
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:392:in `call'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:392:in `execute'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:392:in `each'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:392:in `execute'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:362:in `invoke'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:355:in `synchronize'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:355:in `invoke'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1739:in `top_level'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1739:in `each'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1739:in `top_level'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1761:in `standard_exception_handling'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1733:in `top_level'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1711:in `run'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1761:in `standard_exception_handling'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1708:in `run'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/bin/rake:7
/usr/local/bin/rake:16:in `load'
/usr/local/bin/rake:16


I've tried this both with mysql and the sqlite3 in memory database.  Both return the same error.



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

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

From noreply at rubyforge.org  Mon Nov 12 11:56:56 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 12 Nov 2007 11:56:56 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15584 ] Rspec Build Fails with rails
	1.2.4
Message-ID: <20071112165656.1E23C1858632@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: Rspec Build Fails with rails 1.2.4

Initial Comment:

With a brand new trunk with no changes (at revision 2879), rake pre_commit fails when building rails 1.2.4.  Here is the error message that I'm getting (with  cd example_rails_app/; rake -f Multirails.rake pre_commit --trace):

#####################################################
running pre_commit against rails 1.2.4
#####################################################
#####################################################
Removing generated files:
#####################################################
#####################################################
Migrating down and reverting config/routes.rb
#####################################################
rake aborted!
no such file to load -- /Users/smt/play/rspec/example_rails_app/vendor/rails/1.2.4/railties/lib/initializer
/usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require'
/usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'
/Users/smt/play/rspec/example_rails_app/config/boot.rb:27
/usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require'
/usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'
/Users/smt/play/rspec/example_rails_app/rakefile:4
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1940:in `load'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1940:in `raw_load_rakefile'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1727:in `load_rakefile'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1761:in `standard_exception_handling'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1726:in `load_rakefile'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1710:in `run'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1761:in `standard_exception_handling'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1708:in `run'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/bin/rake:7
/usr/local/bin/rake:16:in `load'
/usr/local/bin/rake:16
(in /Users/smt/play/rspec/example_rails_app)
running against rails 1.2.4
rake aborted!
ERROR while running rake: rake db:migrate VERSION=4 --trace
/Users/smt/play/rspec/pre_commit/lib/pre_commit/pre_commit.rb:19:in `rake_sh'
/Users/smt/play/rspec/pre_commit/lib/pre_commit/rspec_on_rails.rb:169:in `migrate_down'
/Users/smt/play/rspec/pre_commit/lib/pre_commit/rspec_on_rails.rb:158:in `destroy_purchase'
/Users/smt/play/rspec/pre_commit/lib/pre_commit/rspec_on_rails.rb:49:in `cleanup'
/Users/smt/play/rspec/pre_commit/lib/pre_commit/rspec_on_rails.rb:32:in `rspec_pre_commit'
/Users/smt/play/rspec/pre_commit/lib/pre_commit/rspec_on_rails.rb:9:in `pre_commit'
/Users/smt/play/rspec/pre_commit/lib/pre_commit/rspec_on_rails.rb:6:in `each'
/Users/smt/play/rspec/pre_commit/lib/pre_commit/rspec_on_rails.rb:6:in `pre_commit'
/Users/smt/play/rspec/example_rails_app/Multirails.rake:7
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:392:in `call'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:392:in `execute'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:392:in `each'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:392:in `execute'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:362:in `invoke'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:355:in `synchronize'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:355:in `invoke'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1739:in `top_level'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1739:in `each'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1739:in `top_level'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1761:in `standard_exception_handling'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1733:in `top_level'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1711:in `run'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1761:in `standard_exception_handling'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1708:in `run'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/bin/rake:7
/usr/local/bin/rake:16:in `load'
/usr/local/bin/rake:16


I've tried this both with mysql and the sqlite3 in memory database.  Both return the same error.



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

>Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-11-12 16:56

Message:
Close this one, too.  It was just me being stupid.

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

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

From noreply at rubyforge.org  Mon Nov 12 11:59:35 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 12 Nov 2007 11:59:35 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15584 ] Rspec Build Fails with rails
	1.2.4
Message-ID: <20071112165935.9BF191858624@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: Rspec Build Fails with rails 1.2.4

Initial Comment:

With a brand new trunk with no changes (at revision 2879), rake pre_commit fails when building rails 1.2.4.  Here is the error message that I'm getting (with  cd example_rails_app/; rake -f Multirails.rake pre_commit --trace):

#####################################################
running pre_commit against rails 1.2.4
#####################################################
#####################################################
Removing generated files:
#####################################################
#####################################################
Migrating down and reverting config/routes.rb
#####################################################
rake aborted!
no such file to load -- /Users/smt/play/rspec/example_rails_app/vendor/rails/1.2.4/railties/lib/initializer
/usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require'
/usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'
/Users/smt/play/rspec/example_rails_app/config/boot.rb:27
/usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require'
/usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'
/Users/smt/play/rspec/example_rails_app/rakefile:4
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1940:in `load'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1940:in `raw_load_rakefile'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1727:in `load_rakefile'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1761:in `standard_exception_handling'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1726:in `load_rakefile'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1710:in `run'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1761:in `standard_exception_handling'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1708:in `run'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/bin/rake:7
/usr/local/bin/rake:16:in `load'
/usr/local/bin/rake:16
(in /Users/smt/play/rspec/example_rails_app)
running against rails 1.2.4
rake aborted!
ERROR while running rake: rake db:migrate VERSION=4 --trace
/Users/smt/play/rspec/pre_commit/lib/pre_commit/pre_commit.rb:19:in `rake_sh'
/Users/smt/play/rspec/pre_commit/lib/pre_commit/rspec_on_rails.rb:169:in `migrate_down'
/Users/smt/play/rspec/pre_commit/lib/pre_commit/rspec_on_rails.rb:158:in `destroy_purchase'
/Users/smt/play/rspec/pre_commit/lib/pre_commit/rspec_on_rails.rb:49:in `cleanup'
/Users/smt/play/rspec/pre_commit/lib/pre_commit/rspec_on_rails.rb:32:in `rspec_pre_commit'
/Users/smt/play/rspec/pre_commit/lib/pre_commit/rspec_on_rails.rb:9:in `pre_commit'
/Users/smt/play/rspec/pre_commit/lib/pre_commit/rspec_on_rails.rb:6:in `each'
/Users/smt/play/rspec/pre_commit/lib/pre_commit/rspec_on_rails.rb:6:in `pre_commit'
/Users/smt/play/rspec/example_rails_app/Multirails.rake:7
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:392:in `call'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:392:in `execute'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:392:in `each'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:392:in `execute'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:362:in `invoke'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:355:in `synchronize'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:355:in `invoke'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1739:in `top_level'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1739:in `each'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1739:in `top_level'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1761:in `standard_exception_handling'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1733:in `top_level'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1711:in `run'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1761:in `standard_exception_handling'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1708:in `run'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/bin/rake:7
/usr/local/bin/rake:16:in `load'
/usr/local/bin/rake:16


I've tried this both with mysql and the sqlite3 in memory database.  Both return the same error.



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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-12 16:59

Message:
I've been thinking we shouldn't really support 1.2.4 anyway. It was out for a day or two, and was quickly followed up by 1.2.5, which was immediately recommended for anyone who had upgraded to 1.2.4.

WDYT?

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-11-12 16:56

Message:
Close this one, too.  It was just me being stupid.

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

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

From noreply at rubyforge.org  Mon Nov 12 12:00:15 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 12 Nov 2007 12:00:15 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15584 ] Rspec Build Fails with rails
	1.2.4
Message-ID: <20071112170016.08B661858624@rubyforge.org>

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

Category: None
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: Rspec Build Fails with rails 1.2.4

Initial Comment:

With a brand new trunk with no changes (at revision 2879), rake pre_commit fails when building rails 1.2.4.  Here is the error message that I'm getting (with  cd example_rails_app/; rake -f Multirails.rake pre_commit --trace):

#####################################################
running pre_commit against rails 1.2.4
#####################################################
#####################################################
Removing generated files:
#####################################################
#####################################################
Migrating down and reverting config/routes.rb
#####################################################
rake aborted!
no such file to load -- /Users/smt/play/rspec/example_rails_app/vendor/rails/1.2.4/railties/lib/initializer
/usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require'
/usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'
/Users/smt/play/rspec/example_rails_app/config/boot.rb:27
/usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require'
/usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'
/Users/smt/play/rspec/example_rails_app/rakefile:4
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1940:in `load'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1940:in `raw_load_rakefile'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1727:in `load_rakefile'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1761:in `standard_exception_handling'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1726:in `load_rakefile'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1710:in `run'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1761:in `standard_exception_handling'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1708:in `run'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/bin/rake:7
/usr/local/bin/rake:16:in `load'
/usr/local/bin/rake:16
(in /Users/smt/play/rspec/example_rails_app)
running against rails 1.2.4
rake aborted!
ERROR while running rake: rake db:migrate VERSION=4 --trace
/Users/smt/play/rspec/pre_commit/lib/pre_commit/pre_commit.rb:19:in `rake_sh'
/Users/smt/play/rspec/pre_commit/lib/pre_commit/rspec_on_rails.rb:169:in `migrate_down'
/Users/smt/play/rspec/pre_commit/lib/pre_commit/rspec_on_rails.rb:158:in `destroy_purchase'
/Users/smt/play/rspec/pre_commit/lib/pre_commit/rspec_on_rails.rb:49:in `cleanup'
/Users/smt/play/rspec/pre_commit/lib/pre_commit/rspec_on_rails.rb:32:in `rspec_pre_commit'
/Users/smt/play/rspec/pre_commit/lib/pre_commit/rspec_on_rails.rb:9:in `pre_commit'
/Users/smt/play/rspec/pre_commit/lib/pre_commit/rspec_on_rails.rb:6:in `each'
/Users/smt/play/rspec/pre_commit/lib/pre_commit/rspec_on_rails.rb:6:in `pre_commit'
/Users/smt/play/rspec/example_rails_app/Multirails.rake:7
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:392:in `call'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:392:in `execute'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:392:in `each'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:392:in `execute'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:362:in `invoke'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:355:in `synchronize'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:355:in `invoke'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1739:in `top_level'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1739:in `each'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1739:in `top_level'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1761:in `standard_exception_handling'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1733:in `top_level'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1711:in `run'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1761:in `standard_exception_handling'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1708:in `run'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/bin/rake:7
/usr/local/bin/rake:16:in `load'
/usr/local/bin/rake:16


I've tried this both with mysql and the sqlite3 in memory database.  Both return the same error.



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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-12 17:00

Message:
Closed per poster request.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-12 16:59

Message:
I've been thinking we shouldn't really support 1.2.4 anyway. It was out for a day or two, and was quickly followed up by 1.2.5, which was immediately recommended for anyone who had upgraded to 1.2.4.

WDYT?

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-11-12 16:56

Message:
Close this one, too.  It was just me being stupid.

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

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

From noreply at rubyforge.org  Mon Nov 12 12:00:58 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 12 Nov 2007 12:00:58 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15546 ] Rspec Build Fails
Message-ID: <20071112170058.AEB79185863A@rubyforge.org>

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

Category: None
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 2
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: Rspec Build Fails

Initial Comment:

The rspec build is failing for me, @ revision 2848.  After the specs run (with rake spec) and all pass, I get the following error:

/usr/local/lib/ruby/1.8/rexml/text.rb:292:in `normalize': private method `gsub' called for 0:Fixnum (NoMethodError)

Attached, below, is the output:


escher: svn up; svn info; pwd; rake verify_rcov
At revision 2848.
Path: .
URL: svn://rubyforge.org/var/svn/rspec/trunk/rspec
Repository Root: svn://rubyforge.org/var/svn/rspec
Repository UUID: 410327ef-2207-0410-a325-f78bbcb22a5a
Revision: 2848
Node Kind: directory
Schedule: normal
Last Changed Author: aslak_hellesoy
Last Changed Rev: 2847
Last Changed Date: 2007-11-10 17:31:31 -0500 (Sat, 10 Nov 2007)

/Users/smt/play/rspec/rspec
(in /Users/smt/play/rspec/rspec)
Profiling enabled.
.........................................................................................................................................................................................................................P......P...........................................................................................................................P.................................................................................................................................................................................................................................................P....................................................................................................................................................................................................................................P........................................................................................................................................................................................

  Given given.
  And no match (PENDING).

  When when.
  And no match (PENDING).

  Then then.
  And no match (PENDING)...............................................................................................................................................................................


Top 10 slowest examples:
1.2913050 Translator should translate files
0.6018740 Test::Unit interaction runs tests and specs
0.6006520 Spec::Runner::CommandLine when tests are run, output test/unit sumary
0.5934550 Spec::Runner::CommandLine should not output twice
0.5880460 Test::Unit interaction monkey patches AutoRunner
0.5840390 Spec::Runner::CommandLine should not output twice
0.5830880 Spec::Runner::CommandLine when no tests are run, does not output test/unit summary
0.5290180 The bin/spec script should have no warnings
0.4790760 HtmlFormatter should produce HTML identical to the one we designed manually with --diff
0.4294800 Spec::Runner::CommandLine.run should run directory

Pending:
Object#should should raise error if it receives no argument and it is not used as a left side of an operator (Is it even possible to catch this?)
Object#should_not should raise error if it receives no argument and it is not used as a left side of an operator (Is it even possible to catch this?)
should exist, outside of a behavior should pass if target exists (need to either find a way to include stock predicate matchers in Spec::Matchers or add Bret's Exist matcher)
a Mock expectation should fail right away when method defined as never is received (Used to pass (false positive). Which one is wrong, the spec or the actual behavior?)
OptionParser should print help to stdout if no args (TODO)

Finished in 15.896248 seconds

1184 examples, 0 failures, 5 pending
/usr/local/lib/ruby/1.8/rexml/text.rb:292:in `normalize': private method `gsub' called for 0:Fixnum (NoMethodError)
        from /usr/local/lib/ruby/1.8/rexml/element.rb:1084:in `[]='
        from /usr/local/lib/ruby/1.8/rexml/element.rb:586:in `add_attribute'
        from (eval):490:in `table_'
        from (eval):490:in `each'
        from (eval):490:in `table_'
        from (eval):490:in `each'
        from (eval):490:in `table_'
        from /usr/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/lib/rcov/report.rb:702:in `format_overview'
         ... 61 levels...
        from /usr/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/lib/rcov.rb:628:in `dump_coverage_info'
        from /usr/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/lib/rcov.rb:628:in `each'
        from /usr/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/lib/rcov.rb:628:in `dump_coverage_info'
        from /usr/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/bin/rcov:405
rake aborted!
No such file or directory - ../doc/output/coverage/index.html

(See full trace by running task with --trace)




I'm running on OS X.4.10.  Here is my gem list:



escher: gem list --local

*** LOCAL GEMS ***

actionmailer (1.3.5, 1.3.3)
    Service layer for easy email delivery and testing.

actionpack (1.13.5, 1.13.3)
    Web-flow and rendering framework putting the VC in MVC.

actionwebservice (1.2.5, 1.2.3)
    Web service support for Action Pack.

activerecord (1.15.5, 1.15.3)
    Implements the ActiveRecord pattern for ORM.

activesupport (1.4.4, 1.4.2)
    Support and utility classes used by the Rails framework.

autometric (0.0.1)
    Continuously analyzes your code with rcov, saikuro, and flog

capistrano (2.1.0, 2.0.0, 1.4.1)
    Capistrano is a utility and framework for executing commands in
    parallel on multiple remote machines, via SSH.

capistrano-ext (1.2.0)
    Capistrano Extensions is a set of useful task libraries and methods
    that     other developers may reference in their own recipe files.

cgi_multipart_eof_fix (2.5.0, 2.3)
    Fix an exploitable bug in CGI multipart parsing.

cmdparse (2.0.2)
    Advanced command line parser supporting commands

daemons (1.0.9, 1.0.8)
    A toolkit to create and control daemons in different ways

deprec (1.9.0)
    deployment recipes for capistrano

diff-lcs (1.1.2)
    Provides a list of changes that represent the difference between two
    sequenced collections.

fastthread (1.0.1, 1.0)
    Optimized replacement for thread.rb primitives

gem_plugin (0.2.3, 0.2.2)
    A plugin system based on rubygems that uses dependencies only

gruff (0.2.9, 0.2.8)
    Beautiful graphs for one or multiple datasets.

heckle (1.4.1)
    Unit Test Sadism

highline (1.4.0)
    HighLine is a high-level command-line IO library.

hoe (1.3.0)
    Hoe is a way to write Rakefiles much easier and cleaner.

hpricot (0.6)
    a swift, liberal HTML parser with a fantastic library

memcache-client (1.5.0)
    A Ruby memcached client

mini_magick (1.2.3)
    A simple image manipulation library based on ImageMagick.

mongrel (1.1, 1.0.3, 1.0.2, 1.0.1)
    A small fast HTTP library and server that runs Rails, Camping, Nitro
    and Iowa apps.

mongrel_cluster (1.0.4, 1.0.3, 1.0.2)
    Mongrel plugin that provides commands and Capistrano tasks for
    managing multiple Mongrel processes.

needle (1.3.0)
    Needle is a Dependency Injection/Inversion of Control container for
    Ruby. It supports both type-2 (setter) and type-3 (constructor)
    injection. It takes advantage of the dynamic nature of Ruby to
    provide a rich and flexible approach to injecting dependencies.

net-sftp (1.1.0)
    Net::SFTP is a pure-Ruby implementation of the SFTP client protocol.

net-ssh (1.1.2)
    Net::SSH is a pure-Ruby implementation of the SSH2 client protocol.

ParseTree (2.0.2)
    ParseTree is a C extension (using RubyInline) that extracts the
    parse tree for an entire class or a specific method and returns it
    as a s-expression (aka sexp) using ruby's arrays, strings, symbols,
    and integers.

rails (1.2.5, 1.2.3)
    Web-application framework with template engine, control-flow layer,
    and ORM.

railsmachine (1.0.0, 0.1.2)
    The Rails Machine task library

rake (0.7.3)
    Ruby based make-like utility.

rcov (0.8.0.2)
    Code coverage analysis tool for Ruby

RedCloth (3.0.4)
    RedCloth is a module for using Textile and Markdown in Ruby. Textile
    and Markdown are text formats.  A very simple text format. Another
    stab at making readable text that can be converted to HTML.

rspec (1.0.8)
    RSpec-1.0.8 (r2338) - BDD for Ruby http://rspec.rubyforge.org/

ruby-debug (0.9.3)
    Command line interface (CLI) for ruby-debug-base

ruby-debug-base (0.9.3)
    Fast Ruby debugger

ruby2ruby (1.1.7)
    ruby2ruby provides a means of generating pure ruby code easily from
    ParseTree's Sexps.

rubyforge (0.4.4)
    A script which automates a limited set of rubyforge operations.

RubyInline (3.6.5, 3.6.4)
    Ruby Inline is an analog to Perl's Inline::C. Out of the box, it
    allows you to embed C/++ external module code in your ruby script
    directly.

sources (0.0.1)
    This package provides download sources for remote gem installation

sqlite3-ruby (1.2.1)
    SQLite3/Ruby is a module to allow Ruby scripts to interface with a
    SQLite3 database.

syntax (1.0.0)
    Syntax is Ruby library for performing simple syntax highlighting.

webgen (0.4.6)
    webgen is a templated based static Web site generator.

ZenTest (3.6.1)
    ZenTest provides 4 different tools and 1 library: zentest,
    unit_diff, autotest, multiruby, and Test::Rails.
escher: 




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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-12 17:00

Message:
Closed per poster request.

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-11-12 16:40

Message:
No longer having this problem at revision 2879.  You can
close this ticket (thanks if you've fixed it).

Scott


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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-11-12 00:01

Message:
Tried to monkey patch it, but didn't get far (didn't get it
to work).  

Anyway - I've got a patch thats ready to go.  I know that
rspec's internals are changing pretty rapidly, so I'd like
to get this into rspec core sooner rather than later.  

Would it be ok to send you the patch before pre_commit?  Or
maybe you could tell me what version of rcov & rexml you are
using?

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-11-11 12:27

Message:
This is RCov/REXML bugs. A little annoying, but not a big deal. I'm unable to reproduce it on my mac though.

Can you try to monkey patch REXML on the line where the error is thrown to make it work all way through?

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

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

From noreply at rubyforge.org  Mon Nov 12 12:13:24 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 12 Nov 2007 12:13:24 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15584 ] Rspec Build Fails with rails
	1.2.4
Message-ID: <20071112171324.D6DD21858615@rubyforge.org>

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

Category: None
Group: None
Status: Closed
Resolution: Rejected
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: Rspec Build Fails with rails 1.2.4

Initial Comment:

With a brand new trunk with no changes (at revision 2879), rake pre_commit fails when building rails 1.2.4.  Here is the error message that I'm getting (with  cd example_rails_app/; rake -f Multirails.rake pre_commit --trace):

#####################################################
running pre_commit against rails 1.2.4
#####################################################
#####################################################
Removing generated files:
#####################################################
#####################################################
Migrating down and reverting config/routes.rb
#####################################################
rake aborted!
no such file to load -- /Users/smt/play/rspec/example_rails_app/vendor/rails/1.2.4/railties/lib/initializer
/usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require'
/usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'
/Users/smt/play/rspec/example_rails_app/config/boot.rb:27
/usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require'
/usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'
/Users/smt/play/rspec/example_rails_app/rakefile:4
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1940:in `load'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1940:in `raw_load_rakefile'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1727:in `load_rakefile'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1761:in `standard_exception_handling'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1726:in `load_rakefile'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1710:in `run'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1761:in `standard_exception_handling'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1708:in `run'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/bin/rake:7
/usr/local/bin/rake:16:in `load'
/usr/local/bin/rake:16
(in /Users/smt/play/rspec/example_rails_app)
running against rails 1.2.4
rake aborted!
ERROR while running rake: rake db:migrate VERSION=4 --trace
/Users/smt/play/rspec/pre_commit/lib/pre_commit/pre_commit.rb:19:in `rake_sh'
/Users/smt/play/rspec/pre_commit/lib/pre_commit/rspec_on_rails.rb:169:in `migrate_down'
/Users/smt/play/rspec/pre_commit/lib/pre_commit/rspec_on_rails.rb:158:in `destroy_purchase'
/Users/smt/play/rspec/pre_commit/lib/pre_commit/rspec_on_rails.rb:49:in `cleanup'
/Users/smt/play/rspec/pre_commit/lib/pre_commit/rspec_on_rails.rb:32:in `rspec_pre_commit'
/Users/smt/play/rspec/pre_commit/lib/pre_commit/rspec_on_rails.rb:9:in `pre_commit'
/Users/smt/play/rspec/pre_commit/lib/pre_commit/rspec_on_rails.rb:6:in `each'
/Users/smt/play/rspec/pre_commit/lib/pre_commit/rspec_on_rails.rb:6:in `pre_commit'
/Users/smt/play/rspec/example_rails_app/Multirails.rake:7
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:392:in `call'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:392:in `execute'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:392:in `each'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:392:in `execute'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:362:in `invoke'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:355:in `synchronize'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:355:in `invoke'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1739:in `top_level'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1739:in `each'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1739:in `top_level'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1761:in `standard_exception_handling'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1733:in `top_level'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1711:in `run'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1761:in `standard_exception_handling'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1708:in `run'
/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/bin/rake:7
/usr/local/bin/rake:16:in `load'
/usr/local/bin/rake:16


I've tried this both with mysql and the sqlite3 in memory database.  Both return the same error.



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

>Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-11-12 17:13

Message:
David: My thoughts exactly.


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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-12 17:00

Message:
Closed per poster request.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-12 16:59

Message:
I've been thinking we shouldn't really support 1.2.4 anyway. It was out for a day or two, and was quickly followed up by 1.2.5, which was immediately recommended for anyone who had upgraded to 1.2.4.

WDYT?

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-11-12 16:56

Message:
Close this one, too.  It was just me being stupid.

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

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

From noreply at rubyforge.org  Mon Nov 12 12:25:56 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 12 Nov 2007 12:25:56 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-15587 ] Run behaviours with
	--behaviour (or -B)
Message-ID: <20071112172556.7C20518585B1@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: Run behaviours with --behaviour (or -B)

Initial Comment:

We can run individual examples with the command switch --example "MyFoo should do bar".  This patch adds the ability to specify the name of the behaviour block with --behaviour (and -B), which would run all the specs under that behaviour name.



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

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

From noreply at rubyforge.org  Mon Nov 12 12:30:57 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 12 Nov 2007 12:30:57 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-15587 ] Run behaviours with
	--behaviour (or -B)
Message-ID: <20071112173057.5F2AB18585D4@rubyforge.org>

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

Category: None
Group: None
>Status: Closed
>Resolution: Out of Date
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: Run behaviours with --behaviour (or -B)

Initial Comment:

We can run individual examples with the command switch --example "MyFoo should do bar".  This patch adds the ability to specify the name of the behaviour block with --behaviour (and -B), which would run all the specs under that behaviour name.



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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-12 17:30

Message:
You can already do that!

Just say --example "MyFoo".

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

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

From brian.takita at gmail.com  Mon Nov 12 12:28:12 2007
From: brian.takita at gmail.com (Brian Takita)
Date: Mon, 12 Nov 2007 09:28:12 -0800
Subject: [rspec-devel] it "should [action] ..." vs it with an active voice
Message-ID: <1d7ddd110711120928g55d65b6ai6c6e53f091b8e7f@mail.gmail.com>

I'd like to start gathering information/debating on the
advantages/disadvantages of using it "should ..." vs other techniques.

Dan North explained why we should use should:
http://dannorth.net/introducing-bdd/

I used to use it "should ..." for the projects I was on, until I was
challenged by a fellow developer who started using it with an active
voice.
For example instead of:
it "should go to the park"
An active voice would be:
it "goes to the park"

After a few days of reluctance (or stubbornly hanging on to the rspec
"convention"), I eventually adopted and grown to love using the active
voice.

Here are the main reasons that I prefer an active voice because:
* using it "should ..." over and over renders should meaningless (I
have grown this barely conscience aversion to the word 'should')
* less less words are needed
* the differentiating information of the 'it' statement is in the
front, rather than hidden behind should (space to the left is at a
premium)
* it describes what the software will do and what it does (both from
the Test Driven Design and Regression verification lifecycles of the
test)
* you still have a good "sentence template" that "should" provides
(you have to make a coherent sentence)

So here it my initial stab. Lets discuss :)

Thanks,
Brian

From noreply at rubyforge.org  Mon Nov 12 12:41:58 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 12 Nov 2007 12:41:58 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-15587 ] Run behaviours with
	--behaviour (or -B)
Message-ID: <20071112174158.BC5BB18585E2@rubyforge.org>

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

Category: None
Group: None
Status: Closed
Resolution: Out of Date
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: Run behaviours with --behaviour (or -B)

Initial Comment:

We can run individual examples with the command switch --example "MyFoo should do bar".  This patch adds the ability to specify the name of the behaviour block with --behaviour (and -B), which would run all the specs under that behaviour name.



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

>Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-11-12 17:41

Message:
What!  I had no idea the runner was so intelligent.  Thanks,
guys (and close this one).


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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-12 17:30

Message:
You can already do that!

Just say --example "MyFoo".

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

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

From mvanholstyn at gmail.com  Mon Nov 12 15:54:52 2007
From: mvanholstyn at gmail.com (Mark Van Holstyn)
Date: Mon, 12 Nov 2007 15:54:52 -0500
Subject: [rspec-devel] Aliasing view helpers...
Message-ID: <e45a289c0711121254q366b3474q8dec5fbabb9852a8@mail.gmail.com>

I have one application which aliases some view helpers. The code works fine,
but the specs fail with this error...

~/application/vendor/rails/activesupport/lib/active_support/core_ext/module/aliasing.rb:31:in
`alias_method': undefined method `expand_javascript_sources' for class
`Spec::Rails::DSL::HelperExample' (NameError)
    from
~/application/vendor/rails/activesupport/lib/active_support/core_ext/module/aliasing.rb:31:in
`alias_method_chain'
    from
~/application/vendor/plugins/dhtml_calendar/lib/helpers/calendar.rb:59:in
`included'
    from
~/application/vendor/plugins/dhtml_calendar/lib/helpers/calendar.rb:58:in
`class_eval'
    from
~/application/vendor/plugins/dhtml_calendar/lib/helpers/calendar.rb:58:in
`included'
    from
~/application/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/helper_example.rb:37:in
`include'
    from
~/application/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/helper_example.rb:37
    from
~/application/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/helper_example.rb:36:in
`each'
    from
~/application/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/helper_example.rb:36
     ... 51 levels...
    from
~/application/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:13:in
`load_files'
    from ~/application/vendor/plugins/rspec/lib/spec/runner/options.rb:73:in
`run_examples'
    from
~/application/vendor/plugins/rspec/lib/spec/runner/command_line.rb:19:in
`run'
    from ~/application/vendor/plugins/rspec/bin/spec:3

Looking at the code, I notice this:

ActionView::Base.included_modules.each do |mod|
  include mod if mod.parents.include?(ActionView::Helpers)
end

The problem is that "included_modules" returns the included modules in the
reverse order that they were included.

>> ActionView::Base.included_modules
=> [#<Module:0x192cca4>, ActionController::Routing::Helpers,
ActionController::PolymorphicRoutes, WillPaginate::ViewHelpers,
FileColumnHelper, ActionView::Helpers::DhtmlCalendarHelper,
ActionView::Helpers::UrlHelper, ActionView::Helpers::TextHelper,
ActionView::Helpers::TagHelper, ActionView::Helpers::ScriptaculousHelper,
ActionView::Helpers::SanitizeHelper, ActionView::Helpers::RecordTagHelper,
ActionView::Helpers::RecordIdentificationHelper,
ActionView::Helpers::NumberHelper, ActionView::Helpers::JavaScriptHelper,
ActionView::Helpers::PrototypeHelper, ActionView::Helpers::FormTagHelper,
ActionView::Helpers::FormOptionsHelper, ActionView::Helpers::FormHelper,
ActionView::Helpers::DebugHelper, ActionView::Helpers::DateHelper,
ActionView::Helpers::CaptureHelper, ActionView::Helpers::CacheHelper,
ActionView::Helpers::BenchmarkHelper, ActionView::Helpers::AtomFeedHelper,
ActionView::Helpers::AssetTagHelper,
ActionView::Helpers::ActiveRecordHelper, ActionView::Partials,
ActionView::Base::CompiledTemplates, ERB::Util, InstanceExecMethods,
Base64::Deprecated, Base64, PP::ObjectMixin, Kernel]

My module is now included BEFORE any of the modules provided by rails, so
the alias call fails. I changed the first line of code to reverse the array
returned from included_modules so that they are included in the proper
order, and this did not cause any problems on my application.

ActionView::Base.included_modules.*reverse*.each do |mod|

Thoughts?

Mark

-- 
Mark Van Holstyn, Partner / Software Developer
mvanholstyn at mutuallyhuman.com, (616) 706-6842
Mutually Human Software, http://mutuallyhuman.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20071112/243f0150/attachment.html 

From dchelimsky at gmail.com  Mon Nov 12 15:57:57 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Mon, 12 Nov 2007 14:57:57 -0600
Subject: [rspec-devel] Aliasing view helpers...
In-Reply-To: <e45a289c0711121254q366b3474q8dec5fbabb9852a8@mail.gmail.com>
References: <e45a289c0711121254q366b3474q8dec5fbabb9852a8@mail.gmail.com>
Message-ID: <57c63afe0711121257j2966eee5nacc445d9c58ae75c@mail.gmail.com>

On Nov 12, 2007 2:54 PM, Mark Van Holstyn <mvanholstyn at gmail.com> wrote:
> I have one application which aliases some view helpers. The code works fine,
> but the specs fail with this error...
>
> ~/application/vendor/rails/activesupport/lib/active_support/core_ext/module/aliasing.rb:31:in
> `alias_method': undefined method `expand_javascript_sources' for class
> `Spec::Rails::DSL::HelperExample' (NameError)
>     from
> ~/application/vendor/rails/activesupport/lib/active_support/core_ext/module/aliasing.rb:31:in
> `alias_method_chain'
>     from
> ~/application/vendor/plugins/dhtml_calendar/lib/helpers/calendar.rb:59:in
> `included'
>     from
> ~/application/vendor/plugins/dhtml_calendar/lib/helpers/calendar.rb:58:in
> `class_eval'
>     from
> ~/application/vendor/plugins/dhtml_calendar/lib/helpers/calendar.rb:58:in
> `included'
>     from
> ~/application/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/helper_example.rb:37:in
> `include'
>     from
> ~/application/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/helper_example.rb:37
>     from
> ~/application/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/helper_example.rb:36:in
> `each'
>     from
> ~/application/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/helper_example.rb:36
>      ... 51 levels...
>     from
> ~/application/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:13:in
> `load_files'
>     from ~/application/vendor/plugins/rspec/lib/spec/runner/options.rb:73:in
> `run_examples'
>     from
> ~/application/vendor/plugins/rspec/lib/spec/runner/command_line.rb:19:in
> `run'
>     from ~/application/vendor/plugins/rspec/bin/spec:3
>
> Looking at the code, I notice this:
>
> ActionView::Base.included_modules.each do |mod|
>   include mod if mod.parents.include?(ActionView::Helpers)
> end
>
> The problem is that "included_modules" returns the included modules in the
> reverse order that they were included.
>
> >> ActionView::Base.included_modules
> => [#<Module:0x192cca4>, ActionController::Routing::Helpers,
> ActionController::PolymorphicRoutes, WillPaginate::ViewHelpers,
> FileColumnHelper, ActionView::Helpers::DhtmlCalendarHelper,
> ActionView::Helpers::UrlHelper, ActionView::Helpers::TextHelper,
> ActionView::Helpers::TagHelper, ActionView::Helpers::ScriptaculousHelper,
> ActionView::Helpers::SanitizeHelper, ActionView::Helpers::RecordTagHelper,
> ActionView::Helpers::RecordIdentificationHelper,
> ActionView::Helpers::NumberHelper, ActionView::Helpers::JavaScriptHelper,
> ActionView::Helpers::PrototypeHelper, ActionView::Helpers::FormTagHelper,
> ActionView::Helpers::FormOptionsHelper, ActionView::Helpers::FormHelper,
> ActionView::Helpers::DebugHelper, ActionView::Helpers::DateHelper,
> ActionView::Helpers::CaptureHelper, ActionView::Helpers::CacheHelper,
> ActionView::Helpers::BenchmarkHelper, ActionView::Helpers::AtomFeedHelper,
> ActionView::Helpers::AssetTagHelper,
> ActionView::Helpers::ActiveRecordHelper, ActionView::Partials,
> ActionView::Base::CompiledTemplates, ERB::Util, InstanceExecMethods,
> Base64::Deprecated, Base64, PP::ObjectMixin, Kernel]
>
> My module is now included BEFORE any of the modules provided by rails, so
> the alias call fails. I changed the first line of code to reverse the array
> returned from included_modules so that they are included in the proper
> order, and this did not cause any problems on my application.
>
> ActionView::Base.included_modules.reverse.each do |mod|
>
> Thoughts?

Sounds like a good idea - please submit a patch w/ specs:

http://rubyforge.org/tracker/?group_id=797

Cheers,
David

From noreply at rubyforge.org  Mon Nov 12 22:06:32 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 12 Nov 2007 22:06:32 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-15597 ] [PATCH] Reverse loading of
	ActionView::Base helper modules
Message-ID: <20071113030632.D25E718585F1@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Mark Van Holstyn (lotswholetime)
Assigned to: Nobody (None)
Summary: [PATCH] Reverse loading of ActionView::Base helper modules

Initial Comment:
I have one application which aliases some view helpers. The code works fine, but the specs fail with this error...

~/application/vendor/rails/activesupport/lib/active_support/core_ext/module/aliasing.rb:31:in `alias_method': undefined method `expand_javascript_sources' for class `Spec::Rails::DSL::HelperExample' (NameError)
    from ~/application/vendor/rails/activesupport/lib/active_support/core_ext/module/aliasing.rb:31:in `alias_method_chain'
    from ~/application/vendor/plugins/dhtml_calendar/lib/helpers/calendar.rb:59:in `included'
    from ~/application/vendor/plugins/dhtml_calendar/lib/helpers/calendar.rb:58:in `class_eval'
    from ~/application/vendor/plugins/dhtml_calendar/lib/helpers/calendar.rb:58:in `included'
    from ~/application/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/helper_example.rb:37:in `include'
    from ~/application/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/helper_example.rb:37
    from ~/application/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/helper_example.rb:36:in `each'
    from ~/application/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/helper_example.rb:36
     ... 51 levels...
    from ~/application/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:13:in `load_files'
    from ~/application/vendor/plugins/rspec/lib/spec/runner/options.rb:73:in `run_examples'
    from ~/application/vendor/plugins/rspec/lib/spec/runner/command_line.rb:19:in `run'
    from ~/application/vendor/plugins/rspec/bin/spec:3

Looking at the code, I notice this:

ActionView::Base.included_modules.each do |mod|
  include mod if mod.parents.include?(ActionView::Helpers)
end

The problem is that "included_modules" returns the included modules in the reverse order that they were included.

>> ActionView::Base.included_modules
=> [#<Module:0x192cca4>, ActionController::Routing::Helpers, ActionController::PolymorphicRoutes, WillPaginate::ViewHelpers, FileColumnHelper, ActionView::Helpers::DhtmlCalendarHelper, ActionView::Helpers::UrlHelper, ActionView::Helpers::TextHelper, ActionView::Helpers::TagHelper, ActionView::Helpers::ScriptaculousHelper, ActionView::Helpers::SanitizeHelper, ActionView::Helpers::RecordTagHelper, ActionView::Helpers::RecordIdentificationHelper, ActionView::Helpers::NumberHelper, ActionView::Helpers::JavaScriptHelper, ActionView::Helpers::PrototypeHelper, ActionView::Helpers::FormTagHelper, ActionView::Helpers::FormOptionsHelper, ActionView::Helpers::FormHelper, ActionView::Helpers::DebugHelper, ActionView::Helpers::DateHelper, ActionView::Helpers::CaptureHelper, ActionView::Helpers::CacheHelper, ActionView::Helpers::BenchmarkHelper, ActionView::Helpers::AtomFeedHelper, ActionView::Helpers::AssetTagHelper, ActionView::Helpers::ActiveRecordHelper, ActionView::Partials, ActionView::Base::CompiledTemplates, ERB::Util, InstanceExecMethods, Base64::Deprecated, Base64, PP::ObjectMixin, Kernel]

My module is now included BEFORE any of the modules provided by rails, so the alias call fails. This patch changes the HelperExample definition to  reverse the array returned from included_modules so that they are included in the proper order.


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

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

From mvanholstyn at gmail.com  Mon Nov 12 22:07:30 2007
From: mvanholstyn at gmail.com (Mark Van Holstyn)
Date: Mon, 12 Nov 2007 22:07:30 -0500
Subject: [rspec-devel] Aliasing view helpers...
In-Reply-To: <57c63afe0711121257j2966eee5nacc445d9c58ae75c@mail.gmail.com>
References: <e45a289c0711121254q366b3474q8dec5fbabb9852a8@mail.gmail.com>
	<57c63afe0711121257j2966eee5nacc445d9c58ae75c@mail.gmail.com>
Message-ID: <e45a289c0711121907s7bac1cf7jd094ca6cb9db531@mail.gmail.com>

Done.

http://rubyforge.org/tracker/index.php?func=detail&aid=15597&group_id=797&atid=3151

Let me know how everything looks.

Thanks,

Mark

On Nov 12, 2007 3:57 PM, David Chelimsky <dchelimsky at gmail.com> wrote:

> On Nov 12, 2007 2:54 PM, Mark Van Holstyn <mvanholstyn at gmail.com> wrote:
> > I have one application which aliases some view helpers. The code works
> fine,
> > but the specs fail with this error...
> >
> >
> ~/application/vendor/rails/activesupport/lib/active_support/core_ext/module/aliasing.rb:31:in
> > `alias_method': undefined method `expand_javascript_sources' for class
> > `Spec::Rails::DSL::HelperExample' (NameError)
> >     from
> >
> ~/application/vendor/rails/activesupport/lib/active_support/core_ext/module/aliasing.rb:31:in
> > `alias_method_chain'
> >     from
> >
> ~/application/vendor/plugins/dhtml_calendar/lib/helpers/calendar.rb:59:in
> > `included'
> >     from
> >
> ~/application/vendor/plugins/dhtml_calendar/lib/helpers/calendar.rb:58:in
> > `class_eval'
> >     from
> >
> ~/application/vendor/plugins/dhtml_calendar/lib/helpers/calendar.rb:58:in
> > `included'
> >     from
> >
> ~/application/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/helper_example.rb:37:in
> > `include'
> >     from
> >
> ~/application/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/helper_example.rb:37
> >     from
> >
> ~/application/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/helper_example.rb:36:in
> > `each'
> >     from
> >
> ~/application/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/helper_example.rb:36
> >      ... 51 levels...
> >     from
> >
> ~/application/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:13:in
> > `load_files'
> >     from
> ~/application/vendor/plugins/rspec/lib/spec/runner/options.rb:73:in
> > `run_examples'
> >     from
> > ~/application/vendor/plugins/rspec/lib/spec/runner/command_line.rb:19:in
> > `run'
> >     from ~/application/vendor/plugins/rspec/bin/spec:3
> >
> > Looking at the code, I notice this:
> >
> > ActionView::Base.included_modules.each do |mod|
> >   include mod if mod.parents.include?(ActionView::Helpers)
> > end
> >
> > The problem is that "included_modules" returns the included modules in
> the
> > reverse order that they were included.
> >
> > >> ActionView::Base.included_modules
> > => [#<Module:0x192cca4>, ActionController::Routing::Helpers,
> > ActionController::PolymorphicRoutes, WillPaginate::ViewHelpers,
> > FileColumnHelper, ActionView::Helpers::DhtmlCalendarHelper,
> > ActionView::Helpers::UrlHelper, ActionView::Helpers::TextHelper,
> > ActionView::Helpers::TagHelper,
> ActionView::Helpers::ScriptaculousHelper,
> > ActionView::Helpers::SanitizeHelper,
> ActionView::Helpers::RecordTagHelper,
> > ActionView::Helpers::RecordIdentificationHelper,
> > ActionView::Helpers::NumberHelper,
> ActionView::Helpers::JavaScriptHelper,
> > ActionView::Helpers::PrototypeHelper,
> ActionView::Helpers::FormTagHelper,
> > ActionView::Helpers::FormOptionsHelper, ActionView::Helpers::FormHelper,
> > ActionView::Helpers::DebugHelper, ActionView::Helpers::DateHelper,
> > ActionView::Helpers::CaptureHelper, ActionView::Helpers::CacheHelper,
> > ActionView::Helpers::BenchmarkHelper,
> ActionView::Helpers::AtomFeedHelper,
> > ActionView::Helpers::AssetTagHelper,
> > ActionView::Helpers::ActiveRecordHelper, ActionView::Partials,
> > ActionView::Base::CompiledTemplates, ERB::Util, InstanceExecMethods,
> > Base64::Deprecated, Base64, PP::ObjectMixin, Kernel]
> >
> > My module is now included BEFORE any of the modules provided by rails,
> so
> > the alias call fails. I changed the first line of code to reverse the
> array
> > returned from included_modules so that they are included in the proper
> > order, and this did not cause any problems on my application.
> >
> > ActionView::Base.included_modules.reverse.each do |mod|
> >
> > Thoughts?
>
> Sounds like a good idea - please submit a patch w/ specs:
>
> http://rubyforge.org/tracker/?group_id=797
>
> Cheers,
> David
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>



-- 
Mark Van Holstyn, Partner / Software Developer
mvanholstyn at mutuallyhuman.com, (616) 706-6842
Mutually Human Software, http://mutuallyhuman.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20071112/6f441847/attachment.html 

From noreply at rubyforge.org  Tue Nov 13 07:50:37 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 13 Nov 2007 07:50:37 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15604 ] Cannot use console colouring
	mode without "win32console" gem on Windows.
Message-ID: <20071113125037.9195E1858613@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Roman Chernyatchik (romeo)
Assigned to: Nobody (None)
Summary: Cannot use console colouring mode without "win32console" gem on Windows.

Initial Comment:
Cannot use console colouring mode without "win32console" gem on Windows.

Hi guys! I've written renderer for rspec colouring output, but I cannot use it on Windows platform. Please add opportunity to use colouring mode on Windows without "win32console" gem!

The problem is in base_text_formatter.rb: 

def colour=(colour)
     @colour = colour
     begin ; require 'Win32/Console/ANSI' if @colour && PLATFORM =~ /win32/ ; rescue LoadError ;  raise "You must gem install win32console to use colour on Windows" ; end
end 

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

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

From noreply at rubyforge.org  Tue Nov 13 11:26:59 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 13 Nov 2007 11:26:59 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15604 ] Cannot use console colouring
	mode without "win32console" gem on Windows.
Message-ID: <20071113162659.1A77F18585B4@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
>Resolution: Rejected
Priority: 3
Submitted By: Roman Chernyatchik (romeo)
>Assigned to: Aslak Helles?y (aslak_hellesoy)
>Summary: Cannot use console colouring mode without "win32console" gem on Windows.

Initial Comment:
Cannot use console colouring mode without "win32console" gem on Windows.

Hi guys! I've written renderer for rspec colouring output, but I cannot use it on Windows platform. Please add opportunity to use colouring mode on Windows without "win32console" gem!

The problem is in base_text_formatter.rb: 

def colour=(colour)
     @colour = colour
     begin ; require 'Win32/Console/ANSI' if @colour && PLATFORM =~ /win32/ ; rescue LoadError ;  raise "You must gem install win32console to use colour on Windows" ; end
end 

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

>Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-11-13 11:26

Message:
This makes no sense. You must install the gem to have console colour on windows. The error message even tells you that.

Or tell us how to have colour support without the gem - I don't think it's possible.

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

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

From noreply at rubyforge.org  Tue Nov 13 12:50:37 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 13 Nov 2007 12:50:37 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15608 ] Story problem if parenthesis
	used in Given, When, Then or And
Message-ID: <20071113175037.69DB318585E2@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: sinclair  bain (sinclair)
Assigned to: Nobody (None)
Summary: Story problem if parenthesis used in Given, When, Then or And

Initial Comment:
VERSION: rspec rails plugin current edge version
XP/Cygwin on XP

Hi,
I hit this when trying to use parenthesis in my stories ... (that'll teach me!).

If a scenario looks  like the following:

Story "User has story with parentheses", %{
  As a user
  I want parenthesis
  So that ... well I just do 
}, :type => RailsStory do

  Scenario "the Given has parentheses" do
    Given "parenthesis () in the given " do
    end

    When "anything" do
    end
   
    Then "The error occurred while evaluating nil.perform " do
    end
 
  end
end

This fails with the following:

The error occurred while evaluating nil.perform
  /cygdrive/c/development/sandbox/prototypes/proj/config/../vendor/plugins/rspec/lib/spec/story/world.rb: 60:in `store_and_call'
/cygdrive/c/development/sandbox/prototypes/proj/config/../vendor/plugins/rspec/lib/spec/story/world.rb: 92:in `Given'
stories/parenthesis_error_story.rb:10


Looks like the problem is in the Step#matches? method
since
    "abc (re) def".match /abc (re) def/
returns nil
however
    "abc (re) def".match /abc \(re\) def/
returns the match

The Step#assign_expression method when modifed as follows

        def assign_expression(name)
          expression = name.dup
          if String === expression
            while expression =~ /(\$\w*)/
              expression.gsub!($1, "(.*)")
            end
           
            expression.gsub! '(', '\('     # here
            expression.gsub! ')', '\)'     # here

          end
          @expression = Regexp.new ("^#{expression}$")
        end

Then the specs pass.

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

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

From a.schur at nucleus.com  Tue Nov 13 18:32:23 2007
From: a.schur at nucleus.com (Alvin Schur)
Date: Tue, 13 Nov 2007 16:32:23 -0700
Subject: [rspec-devel] Stories and test data
Message-ID: <473A3407.3050309@nucleus.com>

I am working with oil and gas data supplied by a third-party.

Users want to find wells by:
  a) Status: producing or suspended or abandoned or show
  b) Product: oil or gas or bitumen or water


To perform the search we must look at two fields: plot symbol and 
current status.

Each well can have 1 out of 43 plot symbols (abandoned, injection, gas, 
gas potential, etc)

Each well can have a 1 out of 1037 current statuses (abandoned acid gas, 
suspended acid gas disposal, etc)


How much detail should the Stories and Scenarios provide about the test 
data?

Part of my concern is that explicitly listing wells in the Scenario,  a 
Scenario can pass but the search is wrong by matching more wells than 
are listed as the setup data.

Things get more interesting when we test each combination.

Are there any guidelines for handling combinatorial explosions in Stories?

Some samples are:

  Scenario: search for producing wells (expects well data to already exist)
    Given a licensed user is logged in
    And the user is searching for wells
    And the current well search has a status qualifier
    When the user selects producing wells
    And updates the search count
    Then there should be 15 wells
    And have plot symbols: OIL, GAS, OIL_GAS, WATER, or SAGD
    And have statuses: Flowing CBM & Othr, Flowing CBM Coal, Pumping CBM 
Coal
    And nothing else


  Scenario: search for producing wells
    Given a licensed user is logged in
    And the user is searching for wells
    And the current well search has a status qualifier
    And a well with plot symbol: OIL exists
    And a well with plot symbol: GAS exists
    And a well with plot symbol: OIL_GAS exists
    And a well with plot symbol: WATER exists
    And a well with plot symbol: SAGD exists
    And a well with plot symbol: EXCLUDED exists
    And a well with current status: Flowing CBM & Othr exists
    And a well with current status: Flowing CBM Coal exists
    And a well with current status: Pumping CBM Coal exists
    And a well with current status: EXCLUDED exists
    When the user selects producing wells
    And updates the search count
    Then there should be 8 wells
    And have plot symbols: OIL, GAS
    And have statuses: Flowing CBM & Othr


  Scenario: search for producing wells
    Given a licensed user is logged in
    And the user is searching for wells
    And the current well search has a status qualifier
    And there are wells for each plot symbol and current status 
combination <-- (takes a long time to set up)
    When the user selects producing wells
    And updates the search count
    Then there should be xxx wells
    And have plot symbols: OIL, GAS, OIL_GAS, WATER, or SAGD
    And or have statuses: Flowing CBM & Othr, Flowing CBM Coal, Pumping 
CBM Coal
    And nothing else

Thanks,

Alvin.


From a.schur at nucleus.com  Tue Nov 13 18:49:51 2007
From: a.schur at nucleus.com (Alvin Schur)
Date: Tue, 13 Nov 2007 16:49:51 -0700
Subject: [rspec-devel] Hooks in the story runner
Message-ID: <473A381F.9090002@nucleus.com>

Is there a hook in the story runner that allows me to run code before 
and after each scenario?

My goal is to wrap each Scenario in a transaction to a second database.

Thanks,

Alvin.


From dchelimsky at gmail.com  Tue Nov 13 19:26:43 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 13 Nov 2007 18:26:43 -0600
Subject: [rspec-devel] Hooks in the story runner
In-Reply-To: <473A381F.9090002@nucleus.com>
References: <473A381F.9090002@nucleus.com>
Message-ID: <57c63afe0711131626j1f5786beka5e92293f33b637f@mail.gmail.com>

On Nov 13, 2007 5:49 PM, Alvin Schur <a.schur at nucleus.com> wrote:
> Is there a hook in the story runner that allows me to run code before
> and after each scenario?
>
> My goal is to wrap each Scenario in a transaction to a second database.

There's not now but I'm working on one. I'll follow up later today or tomorrow.

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

From noreply at rubyforge.org  Wed Nov 14 11:37:33 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 14 Nov 2007 11:37:33 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15604 ] Cannot use console colouring
	mode without &quot; win32console&quot; gem on Windows.
Message-ID: <20071114163733.3439218585BC@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Resolution: Rejected
Priority: 3
Submitted By: Roman Chernyatchik (romeo)
Assigned to: Aslak Helles?y (aslak_hellesoy)
>Summary: Cannot use console colouring mode without &quot;win32console&quot; gem on Windows.

Initial Comment:
Cannot use console colouring mode without "win32console" gem on Windows.

Hi guys! I've written renderer for rspec colouring output, but I cannot use it on Windows platform. Please add opportunity to use colouring mode on Windows without "win32console" gem!

The problem is in base_text_formatter.rb: 

def colour=(colour)
     @colour = colour
     begin ; require 'Win32/Console/ANSI' if @colour && PLATFORM =~ /win32/ ; rescue LoadError ;  raise "You must gem install win32console to use colour on Windows" ; end
end 

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

>Comment By: Roman Chernyatchik (romeo)
Date: 2007-11-14 19:37

Message:
We've implemented  colour support in console panel of ROR plugin for IntelliJ 
IDEA.  But "win32console" gem doesn't allow us to redirect output stream thus it 
hides all output from our console even when colour mode is disabled. 

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-11-13 19:26

Message:
This makes no sense. You must install the gem to have console colour on windows. The error message even tells you that.

Or tell us how to have colour support without the gem - I don't think it's possible.

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

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

From noreply at rubyforge.org  Wed Nov 14 19:14:42 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 14 Nov 2007 19:14:42 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15604 ] Cannot use console colouring
	mode without &quot; win32console&quot; gem on Windows.
Message-ID: <20071115001442.2E48C1598061@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
>Resolution: Accepted
Priority: 3
Submitted By: Roman Chernyatchik (romeo)
Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: Cannot use console colouring mode without &quot;win32console&quot; gem on Windows.

Initial Comment:
Cannot use console colouring mode without "win32console" gem on Windows.

Hi guys! I've written renderer for rspec colouring output, but I cannot use it on Windows platform. Please add opportunity to use colouring mode on Windows without "win32console" gem!

The problem is in base_text_formatter.rb: 

def colour=(colour)
     @colour = colour
     begin ; require 'Win32/Console/ANSI' if @colour && PLATFORM =~ /win32/ ; rescue LoadError ;  raise "You must gem install win32console to use colour on Windows" ; end
end 

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

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

Message:
So what's your suggestion for coloured console output without the win32console gem?

Would it help if you could give --colour an argument like:

--colour MyColourer

where MyColourer is some alternative (your?) implementation of colouring?

Can you submit a patch? (I'm reopening this now that I think I understand what you mean)

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

Comment By: Roman Chernyatchik (romeo)
Date: 2007-11-14 11:37

Message:
We've implemented  colour support in console panel of ROR plugin for IntelliJ 
IDEA.  But "win32console" gem doesn't allow us to redirect output stream thus it 
hides all output from our console even when colour mode is disabled. 

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-11-13 11:26

Message:
This makes no sense. You must install the gem to have console colour on windows. The error message even tells you that.

Or tell us how to have colour support without the gem - I don't think it's possible.

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

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

From ben at benmabey.com  Wed Nov 14 22:16:48 2007
From: ben at benmabey.com (Ben Mabey)
Date: Wed, 14 Nov 2007 20:16:48 -0700
Subject: [rspec-devel] Formatting of stories
Message-ID: <473BBA20.8000301@benmabey.com>

Are there plans to have a "story" command similar to the "spec" command 
to run and format your stories?  Or will it be integrated into spec?  
I'm mostly curious about having the HTML formatting for the stories.  
Thanks,
Ben

From dchelimsky at gmail.com  Wed Nov 14 22:37:25 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 14 Nov 2007 21:37:25 -0600
Subject: [rspec-devel] Formatting of stories
In-Reply-To: <473BBA20.8000301@benmabey.com>
References: <473BBA20.8000301@benmabey.com>
Message-ID: <57c63afe0711141937k738ea6ci58be14e6d30a601d@mail.gmail.com>

On Nov 14, 2007 9:16 PM, Ben Mabey <ben at benmabey.com> wrote:
> Are there plans to have a "story" command similar to the "spec" command
> to run and format your stories?  Or will it be integrated into spec?
> I'm mostly curious about having the HTML formatting for the stories.

Not exactly sure how it's going to work, but there will definitely be
a way to get html output (once we build it!)

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

From dchelimsky at gmail.com  Wed Nov 14 22:57:59 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 14 Nov 2007 21:57:59 -0600
Subject: [rspec-devel] Hooks in the story runner
In-Reply-To: <57c63afe0711131626j1f5786beka5e92293f33b637f@mail.gmail.com>
References: <473A381F.9090002@nucleus.com>
	<57c63afe0711131626j1f5786beka5e92293f33b637f@mail.gmail.com>
Message-ID: <57c63afe0711141957q7bdb1853h955b6ea9f3df23de@mail.gmail.com>

On Nov 13, 2007 6:26 PM, David Chelimsky <dchelimsky at gmail.com> wrote:
> On Nov 13, 2007 5:49 PM, Alvin Schur <a.schur at nucleus.com> wrote:
> > Is there a hook in the story runner that allows me to run code before
> > and after each scenario?
> >
> > My goal is to wrap each Scenario in a transaction to a second database.
>
> There's not now but I'm working on one. I'll follow up later today or tomorrow.

Following up:

I just committed an update that includes a hook that is NOT well
documented, but works like this:

Spec::Story::Runner.register_listener(listener)

There are a number of messages that get sent to the listeners. Just
implement the ones you want and override method_missing to ignore the
others.

This will get doco soon, but I wanted to get this into trunk so you
could use it :)

As with all things StoryRunner at the moment, this is experimental and
subject to change. There WILL be a way to register a listener, so you
won't lose the capability. It's just that until we officially publish
an API for it, the hook might change (in name only) and the messages
might change as well. Probably not.

Cheers,
David

From tmorgan99 at gmail.com  Wed Nov 14 23:51:00 2007
From: tmorgan99 at gmail.com (Tim Morgan)
Date: Wed, 14 Nov 2007 20:51:00 -0800
Subject: [rspec-devel] Rails 2.0 RC1
Message-ID: <1f3be0490711142051sa097f7clfbd4533876c56d9@mail.gmail.com>

Hello.
I found I had to make the following patches to account for differences
in Rails 2.0.0 RC1:

$  svn diff vendor/plugins/rspec_on_rails/
Index: vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/helper.rb
===================================================================
--- vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/helper.rb
      (revision 2885)
+++ vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/helper.rb
      (working copy)
@@ -27,8 +27,8 @@
           include ActionView::Helpers::FormHelper
           include ActionView::Helpers::FormOptionsHelper
           include ActionView::Helpers::FormTagHelper
-          include ActionView::Helpers::JavaScriptHelper
-          include ActionView::Helpers::JavaScriptMacrosHelper
+          include ActionView::Helpers::JavaScriptHelper rescue nil
+          include ActionView::Helpers::JavaScriptMacrosHelper rescue nil
           include ActionView::Helpers::NumberHelper
           include ActionView::Helpers::PaginationHelper rescue nil
#removed after 1.2.3
           include ActionView::Helpers::PrototypeHelper
Index: vendor/plugins/rspec_on_rails/lib/spec/rails.rb
===================================================================
--- vendor/plugins/rspec_on_rails/lib/spec/rails.rb     (revision 2885)
+++ vendor/plugins/rspec_on_rails/lib/spec/rails.rb     (working copy)
@@ -17,7 +17,8 @@
 require File.expand_path("#{dir}/rails/extensions")
 require File.expand_path("#{dir}/rails/matchers")

-Test::Unit.run = true
+require 'test/test_helper'
+  Test::Unit.run = true

 module Spec
   # = Spec::Rails


ie. some ActionView::Helpers are no longer available?
and test/test_helper is not loaded.

Hope it helps!

From noreply at rubyforge.org  Thu Nov 15 02:05:35 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 15 Nov 2007 02:05:35 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15637 ] modules that use included hook
	don't work any more in Spec::Runner.configure
Message-ID: <20071115070535.EF68E18585C1@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Nobody (None)
Summary: modules that use included hook don't work any more in Spec::Runner.configure

Initial Comment:
We made a change recently in trunk in which modules that get included using config, like this:

Spec::Runner.configure do |config|
  config.include(SomeModule)
end

get included directly into the ExampleGroup base class. When ExampleGroup gets subclassed and instantiated, the instances have all the methods defined in the module.

Unfortunately, this is breaking specs for people who exploit the included hook in Ruby modules:

module ControllerSpecHelper
  def self.included(klass)
    klass.extend(ClassMethods)
  end
  
  module ClassMethods
    def it_should_behave_like_an_admin_action(method)
      it 'should require a login' do
        should_require_login do
          eval method.to_s
        end
      end
      
      it 'should require the admin role' do
        should_require_role_of('admin') do
          eval method.to_s
        end
      end
    end
  end

  ...
end

What used to happen is that since the module was included directly in the instance in which the examples ran, that instance got extended with ClassMethods.

Now, the base class is getting extended instead, rendering these helpers ... helpless.



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

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

From noreply at rubyforge.org  Thu Nov 15 02:06:15 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 15 Nov 2007 02:06:15 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15637 ] modules that use included hook
	don't work any more in Spec::Runner.configure
Message-ID: <20071115070615.BCD5D18585D3@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Nobody (None)
Summary: modules that use included hook don't work any more in Spec::Runner.configure

Initial Comment:
We made a change recently in trunk in which modules that get included using config, like this:

Spec::Runner.configure do |config|
  config.include(SomeModule)
end

get included directly into the ExampleGroup base class. When ExampleGroup gets subclassed and instantiated, the instances have all the methods defined in the module.

Unfortunately, this is breaking specs for people who exploit the included hook in Ruby modules:

module ControllerSpecHelper
  def self.included(klass)
    klass.extend(ClassMethods)
  end
  
  module ClassMethods
    def it_should_behave_like_an_admin_action(method)
      it 'should require a login' do
        should_require_login do
          eval method.to_s
        end
      end
      
      it 'should require the admin role' do
        should_require_role_of('admin') do
          eval method.to_s
        end
      end
    end
  end

  ...
end

What used to happen is that since the module was included directly in the instance in which the examples ran, that instance got extended with ClassMethods.

Now, the base class is getting extended instead, rendering these helpers ... helpless.



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

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

Message:
This is as of rev 2887.

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

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

From noreply at rubyforge.org  Thu Nov 15 02:32:06 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 15 Nov 2007 02:32:06 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15638 ] When naming a protected method,
	if it begins with 'should_' it causes it to be treated as an
	example.
Message-ID: <20071115073206.71FC118585C1@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Nathan Sutton (fowlduck)
Assigned to: Nobody (None)
Summary: When naming a protected method, if it begins with 'should_' it causes it to be treated as an example.

Initial Comment:
starting a protected method with should_ causes it to be treated as an example.

edge rails revision: 8146
edge rspec revision: 2889
edge rspec_on_rails revision: 2889

describe SessionsController do

  # a bunch of examples, some that call should_be_logged_in

protected

  def should_be_logged_in
    response.session.should_not be_nil
    session[:user].should_not be_nil
  end

end

When running the spec:

SessionsController should_be_logged_in' FAILED
expected not nil, got nil
./spec/controllers/sessions_controller_spec.rb:111:in `should_be_logged_in'
script/spec:4:


Renamed the method to 'be_logged_in' and all specs then pass.  Line 111, in this case, is 'session[:user].should_not be_nil'.



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

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

From noreply at rubyforge.org  Thu Nov 15 02:34:00 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 15 Nov 2007 02:34:00 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15637 ] modules that use included hook
	don't work any more in Spec::Runner.configure
Message-ID: <20071115073400.1A23118585C9@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Nobody (None)
Summary: modules that use included hook don't work any more in Spec::Runner.configure

Initial Comment:
We made a change recently in trunk in which modules that get included using config, like this:

Spec::Runner.configure do |config|
  config.include(SomeModule)
end

get included directly into the ExampleGroup base class. When ExampleGroup gets subclassed and instantiated, the instances have all the methods defined in the module.

Unfortunately, this is breaking specs for people who exploit the included hook in Ruby modules:

module ControllerSpecHelper
  def self.included(klass)
    klass.extend(ClassMethods)
  end
  
  module ClassMethods
    def it_should_behave_like_an_admin_action(method)
      it 'should require a login' do
        should_require_login do
          eval method.to_s
        end
      end
      
      it 'should require the admin role' do
        should_require_role_of('admin') do
          eval method.to_s
        end
      end
    end
  end

  ...
end

What used to happen is that since the module was included directly in the instance in which the examples ran, that instance got extended with ClassMethods.

Now, the base class is getting extended instead, rendering these helpers ... helpless.



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

Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 01:33

Message:
It's in revision 2889 as well.

My rails edge revision 8146.

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

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

Message:
This is as of rev 2887.

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

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

From noreply at rubyforge.org  Thu Nov 15 02:44:16 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 15 Nov 2007 02:44:16 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15638 ] When naming a protected method,
	if it begins with 'should_' it causes it to be treated as an
	example.
Message-ID: <20071115074416.2668C18585D3@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Nathan Sutton (fowlduck)
Assigned to: Nobody (None)
Summary: When naming a protected method, if it begins with 'should_' it causes it to be treated as an example.

Initial Comment:
starting a protected method with should_ causes it to be treated as an example.

edge rails revision: 8146
edge rspec revision: 2889
edge rspec_on_rails revision: 2889

describe SessionsController do

  # a bunch of examples, some that call should_be_logged_in

protected

  def should_be_logged_in
    response.session.should_not be_nil
    session[:user].should_not be_nil
  end

end

When running the spec:

SessionsController should_be_logged_in' FAILED
expected not nil, got nil
./spec/controllers/sessions_controller_spec.rb:111:in `should_be_logged_in'
script/spec:4:


Renamed the method to 'be_logged_in' and all specs then pass.  Line 111, in this case, is 'session[:user].should_not be_nil'.



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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-15 07:44

Message:
That's actually by design. In an effort to play well with others, we're working towards a world in which people who prefer to use classes and methods can do this:

class FooSpec < Spec::ExampleGroup
  def should_bar
    ...
  end
end

This works just like Test::Unit except it looks for methods that start with "should" instead of "test". This means that you can not have helper methods that start with "should".

I'm going to leave this ticket open and would welcome opinions on this.

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

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

From noreply at rubyforge.org  Thu Nov 15 02:46:31 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 15 Nov 2007 02:46:31 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15638 ] When naming a protected method,
	if it begins with 'should_' it causes it to be treated as an
	example.
Message-ID: <20071115074631.72F4A18585C9@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Nathan Sutton (fowlduck)
Assigned to: Nobody (None)
Summary: When naming a protected method, if it begins with 'should_' it causes it to be treated as an example.

Initial Comment:
starting a protected method with should_ causes it to be treated as an example.

edge rails revision: 8146
edge rspec revision: 2889
edge rspec_on_rails revision: 2889

describe SessionsController do

  # a bunch of examples, some that call should_be_logged_in

protected

  def should_be_logged_in
    response.session.should_not be_nil
    session[:user].should_not be_nil
  end

end

When running the spec:

SessionsController should_be_logged_in' FAILED
expected not nil, got nil
./spec/controllers/sessions_controller_spec.rb:111:in `should_be_logged_in'
script/spec:4:


Renamed the method to 'be_logged_in' and all specs then pass.  Line 111, in this case, is 'session[:user].should_not be_nil'.



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

>Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 01:46

Message:
Would it be possible to only do this for public methods, and exclude protected 
ones?

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-15 01:44

Message:
That's actually by design. In an effort to play well with others, we're working towards a world in which people who prefer to use classes and methods can do this:

class FooSpec < Spec::ExampleGroup
  def should_bar
    ...
  end
end

This works just like Test::Unit except it looks for methods that start with "should" instead of "test". This means that you can not have helper methods that start with "should".

I'm going to leave this ticket open and would welcome opinions on this.

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

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

From noreply at rubyforge.org  Thu Nov 15 03:00:44 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 15 Nov 2007 03:00:44 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-15639 ] rcov exclusion
	configuration
Message-ID: <20071115080044.B5BED1598061@rubyforge.org>

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

Category: Rake
Group: Next Release (example)
Status: Open
Priority: 3
Submitted By: Nathan Sutton (fowlduck)
Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: rcov exclusion configuration

Initial Comment:
edge rails revision: 8146
edge rspec revision: 2889
edge rspec_on_rails revision: 2889

In the rspec_on_rails rake task in vendor/plugins/rspec_on_rails/tasks/rspec.rake on lines 25-28 you can configure custom spec options (in the spec.opts file), but not add rcov options.  The rcov feature requests I've seen on here may be able to be solved, or at least partially solved, with this feature.

  Spec::Rake::SpecTask.new(:rcov) do |t|
    t.spec_opts = ['--options', "\#{RAILS_ROOT}/spec/spec.opts\"]
    t.spec_files = FileList['spec/**/*_spec.rb']
    t.rcov = true
    t.rcov_opts = ['--exclude', '"spec/*,gems/*,lib/smtp_tls.rb"', '--rails']
  end

If you look, I've added a file to be excluded 'lib/smtp_tls.rb'.


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

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

From noreply at rubyforge.org  Thu Nov 15 04:44:06 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 15 Nov 2007 04:44:06 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-15639 ] rcov exclusion
	configuration
Message-ID: <20071115094406.37C88185856A@rubyforge.org>

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

Category: Rake
Group: Next Release (example)
>Status: Closed
Priority: 3
Submitted By: Nathan Sutton (fowlduck)
Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: rcov exclusion configuration

Initial Comment:
edge rails revision: 8146
edge rspec revision: 2889
edge rspec_on_rails revision: 2889

In the rspec_on_rails rake task in vendor/plugins/rspec_on_rails/tasks/rspec.rake on lines 25-28 you can configure custom spec options (in the spec.opts file), but not add rcov options.  The rcov feature requests I've seen on here may be able to be solved, or at least partially solved, with this feature.

  Spec::Rake::SpecTask.new(:rcov) do |t|
    t.spec_opts = ['--options', "\#{RAILS_ROOT}/spec/spec.opts\"]
    t.spec_files = FileList['spec/**/*_spec.rb']
    t.rcov = true
    t.rcov_opts = ['--exclude', '"spec/*,gems/*,lib/smtp_tls.rb"', '--rails']
  end

If you look, I've added a file to be excluded 'lib/smtp_tls.rb'.


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

>Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-11-15 04:44

Message:
Its' your lucky day - I'd usually ask you to submit a patch.

As of r2890 you have spec/rcov.opts. You must re-install and re-bootstrap the rspec_on_rails plugin to get it.


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

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

From noreply at rubyforge.org  Thu Nov 15 07:35:18 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 15 Nov 2007 07:35:18 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-15639 ] rcov exclusion
	configuration
Message-ID: <20071115123518.E932018585C3@rubyforge.org>

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

Category: Rake
Group: Next Release (example)
Status: Closed
Priority: 3
Submitted By: Nathan Sutton (fowlduck)
Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: rcov exclusion configuration

Initial Comment:
edge rails revision: 8146
edge rspec revision: 2889
edge rspec_on_rails revision: 2889

In the rspec_on_rails rake task in vendor/plugins/rspec_on_rails/tasks/rspec.rake on lines 25-28 you can configure custom spec options (in the spec.opts file), but not add rcov options.  The rcov feature requests I've seen on here may be able to be solved, or at least partially solved, with this feature.

  Spec::Rake::SpecTask.new(:rcov) do |t|
    t.spec_opts = ['--options', "\#{RAILS_ROOT}/spec/spec.opts\"]
    t.spec_files = FileList['spec/**/*_spec.rb']
    t.rcov = true
    t.rcov_opts = ['--exclude', '"spec/*,gems/*,lib/smtp_tls.rb"', '--rails']
  end

If you look, I've added a file to be excluded 'lib/smtp_tls.rb'.


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

>Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 06:35

Message:
Woo! Thank Aslak!

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-11-15 03:44

Message:
Its' your lucky day - I'd usually ask you to submit a patch.

As of r2890 you have spec/rcov.opts. You must re-install and re-bootstrap the rspec_on_rails plugin to get it.


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

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

From noreply at rubyforge.org  Thu Nov 15 09:58:30 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 15 Nov 2007 09:58:30 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15638 ] When naming a protected method,
	if it begins with 'should_' it causes it to be treated as an
	example.
Message-ID: <20071115145830.76ACF18585BC@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Nathan Sutton (fowlduck)
Assigned to: Nobody (None)
Summary: When naming a protected method, if it begins with 'should_' it causes it to be treated as an example.

Initial Comment:
starting a protected method with should_ causes it to be treated as an example.

edge rails revision: 8146
edge rspec revision: 2889
edge rspec_on_rails revision: 2889

describe SessionsController do

  # a bunch of examples, some that call should_be_logged_in

protected

  def should_be_logged_in
    response.session.should_not be_nil
    session[:user].should_not be_nil
  end

end

When running the spec:

SessionsController should_be_logged_in' FAILED
expected not nil, got nil
./spec/controllers/sessions_controller_spec.rb:111:in `should_be_logged_in'
script/spec:4:


Renamed the method to 'be_logged_in' and all specs then pass.  Line 111, in this case, is 'session[:user].should_not be_nil'.



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

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

Message:
I'd sooner kill the feature. That sort of subtlety would make things very confusing.

In my view, the feature is either in or out.

Thoughts?

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

Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 07:46

Message:
Would it be possible to only do this for public methods, and exclude protected 
ones?

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

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

Message:
That's actually by design. In an effort to play well with others, we're working towards a world in which people who prefer to use classes and methods can do this:

class FooSpec < Spec::ExampleGroup
  def should_bar
    ...
  end
end

This works just like Test::Unit except it looks for methods that start with "should" instead of "test". This means that you can not have helper methods that start with "should".

I'm going to leave this ticket open and would welcome opinions on this.

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

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

From noreply at rubyforge.org  Thu Nov 15 11:39:51 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 15 Nov 2007 11:39:51 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15638 ] When naming a protected method,
	if it begins with 'should_' it causes it to be treated as an
	example.
Message-ID: <20071115163951.80A8118585B2@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Nathan Sutton (fowlduck)
Assigned to: Nobody (None)
Summary: When naming a protected method, if it begins with 'should_' it causes it to be treated as an example.

Initial Comment:
starting a protected method with should_ causes it to be treated as an example.

edge rails revision: 8146
edge rspec revision: 2889
edge rspec_on_rails revision: 2889

describe SessionsController do

  # a bunch of examples, some that call should_be_logged_in

protected

  def should_be_logged_in
    response.session.should_not be_nil
    session[:user].should_not be_nil
  end

end

When running the spec:

SessionsController should_be_logged_in' FAILED
expected not nil, got nil
./spec/controllers/sessions_controller_spec.rb:111:in `should_be_logged_in'
script/spec:4:


Renamed the method to 'be_logged_in' and all specs then pass.  Line 111, in this case, is 'session[:user].should_not be_nil'.



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

>Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 10:39

Message:
Maybe not kill it, but make it a configuration option?  Also, I think this is the 
reason that my specs were failing last night concerning the inclusion of the 
module, bug #15637.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-15 08:58

Message:
I'd sooner kill the feature. That sort of subtlety would make things very confusing.

In my view, the feature is either in or out.

Thoughts?

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

Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 01:46

Message:
Would it be possible to only do this for public methods, and exclude protected 
ones?

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-15 01:44

Message:
That's actually by design. In an effort to play well with others, we're working towards a world in which people who prefer to use classes and methods can do this:

class FooSpec < Spec::ExampleGroup
  def should_bar
    ...
  end
end

This works just like Test::Unit except it looks for methods that start with "should" instead of "test". This means that you can not have helper methods that start with "should".

I'm going to leave this ticket open and would welcome opinions on this.

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

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

From noreply at rubyforge.org  Thu Nov 15 11:46:24 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 15 Nov 2007 11:46:24 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15637 ] modules that use included hook
	don't work any more in Spec::Runner.configure
Message-ID: <20071115164624.301B318585BC@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Nobody (None)
Summary: modules that use included hook don't work any more in Spec::Runner.configure

Initial Comment:
We made a change recently in trunk in which modules that get included using config, like this:

Spec::Runner.configure do |config|
  config.include(SomeModule)
end

get included directly into the ExampleGroup base class. When ExampleGroup gets subclassed and instantiated, the instances have all the methods defined in the module.

Unfortunately, this is breaking specs for people who exploit the included hook in Ruby modules:

module ControllerSpecHelper
  def self.included(klass)
    klass.extend(ClassMethods)
  end
  
  module ClassMethods
    def it_should_behave_like_an_admin_action(method)
      it 'should require a login' do
        should_require_login do
          eval method.to_s
        end
      end
      
      it 'should require the admin role' do
        should_require_role_of('admin') do
          eval method.to_s
        end
      end
    end
  end

  ...
end

What used to happen is that since the module was included directly in the instance in which the examples ran, that instance got extended with ClassMethods.

Now, the base class is getting extended instead, rendering these helpers ... helpless.



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

Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 10:46

Message:
Scratch this entire bug, it is completely due to the methods beginning with 'should' and being recognized as examples.  I removed the should_ from the front of the methods and inclusion in the config.include works perfectly.

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

Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 01:33

Message:
It's in revision 2889 as well.

My rails edge revision 8146.

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

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

Message:
This is as of rev 2887.

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

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

From noreply at rubyforge.org  Thu Nov 15 11:48:11 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 15 Nov 2007 11:48:11 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15637 ] modules that use included hook
	don't work any more in Spec::Runner.configure
Message-ID: <20071115164811.161C118585C1@rubyforge.org>

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

Category: None
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Nobody (None)
Summary: modules that use included hook don't work any more in Spec::Runner.configure

Initial Comment:
We made a change recently in trunk in which modules that get included using config, like this:

Spec::Runner.configure do |config|
  config.include(SomeModule)
end

get included directly into the ExampleGroup base class. When ExampleGroup gets subclassed and instantiated, the instances have all the methods defined in the module.

Unfortunately, this is breaking specs for people who exploit the included hook in Ruby modules:

module ControllerSpecHelper
  def self.included(klass)
    klass.extend(ClassMethods)
  end
  
  module ClassMethods
    def it_should_behave_like_an_admin_action(method)
      it 'should require a login' do
        should_require_login do
          eval method.to_s
        end
      end
      
      it 'should require the admin role' do
        should_require_role_of('admin') do
          eval method.to_s
        end
      end
    end
  end

  ...
end

What used to happen is that since the module was included directly in the instance in which the examples ran, that instance got extended with ClassMethods.

Now, the base class is getting extended instead, rendering these helpers ... helpless.



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

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

Message:
Closed per Nathan's request.

Thanks for getting to the root of the problem.

Cheers,
David

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

Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 16:46

Message:
Scratch this entire bug, it is completely due to the methods beginning with 'should' and being recognized as examples.  I removed the should_ from the front of the methods and inclusion in the config.include works perfectly.

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

Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 07:33

Message:
It's in revision 2889 as well.

My rails edge revision 8146.

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

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

Message:
This is as of rev 2887.

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

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

From noreply at rubyforge.org  Thu Nov 15 11:51:48 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 15 Nov 2007 11:51:48 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15638 ] When naming a protected method,
	if it begins with 'should_' it causes it to be treated as an
	example.
Message-ID: <20071115165148.8A62B18585A3@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Nathan Sutton (fowlduck)
Assigned to: Nobody (None)
Summary: When naming a protected method, if it begins with 'should_' it causes it to be treated as an example.

Initial Comment:
starting a protected method with should_ causes it to be treated as an example.

edge rails revision: 8146
edge rspec revision: 2889
edge rspec_on_rails revision: 2889

describe SessionsController do

  # a bunch of examples, some that call should_be_logged_in

protected

  def should_be_logged_in
    response.session.should_not be_nil
    session[:user].should_not be_nil
  end

end

When running the spec:

SessionsController should_be_logged_in' FAILED
expected not nil, got nil
./spec/controllers/sessions_controller_spec.rb:111:in `should_be_logged_in'
script/spec:4:


Renamed the method to 'be_logged_in' and all specs then pass.  Line 111, in this case, is 'session[:user].should_not be_nil'.



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

>Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 10:51

Message:
This is the cause of bug #15637 and the subtlety of it will cause breakage for 
those who don't expect it.  How long did we spend trying to figure this out?

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

Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 10:39

Message:
Maybe not kill it, but make it a configuration option?  Also, I think this is the 
reason that my specs were failing last night concerning the inclusion of the 
module, bug #15637.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-15 08:58

Message:
I'd sooner kill the feature. That sort of subtlety would make things very confusing.

In my view, the feature is either in or out.

Thoughts?

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

Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 01:46

Message:
Would it be possible to only do this for public methods, and exclude protected 
ones?

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-15 01:44

Message:
That's actually by design. In an effort to play well with others, we're working towards a world in which people who prefer to use classes and methods can do this:

class FooSpec < Spec::ExampleGroup
  def should_bar
    ...
  end
end

This works just like Test::Unit except it looks for methods that start with "should" instead of "test". This means that you can not have helper methods that start with "should".

I'm going to leave this ticket open and would welcome opinions on this.

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

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

From noreply at rubyforge.org  Thu Nov 15 14:50:36 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 15 Nov 2007 14:50:36 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15638 ] When naming a protected method,
	if it begins with 'should_' it causes it to be treated as an
	example.
Message-ID: <20071115195036.4686018585CE@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Nathan Sutton (fowlduck)
Assigned to: Nobody (None)
Summary: When naming a protected method, if it begins with 'should_' it causes it to be treated as an example.

Initial Comment:
starting a protected method with should_ causes it to be treated as an example.

edge rails revision: 8146
edge rspec revision: 2889
edge rspec_on_rails revision: 2889

describe SessionsController do

  # a bunch of examples, some that call should_be_logged_in

protected

  def should_be_logged_in
    response.session.should_not be_nil
    session[:user].should_not be_nil
  end

end

When running the spec:

SessionsController should_be_logged_in' FAILED
expected not nil, got nil
./spec/controllers/sessions_controller_spec.rb:111:in `should_be_logged_in'
script/spec:4:


Renamed the method to 'be_logged_in' and all specs then pass.  Line 111, in this case, is 'session[:user].should_not be_nil'.



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

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

Message:
I think we should kill the feature. test_ methods and it blocks is enough. I don't think we need another pit stop in between.

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

Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 11:51

Message:
This is the cause of bug #15637 and the subtlety of it will cause breakage for 
those who don't expect it.  How long did we spend trying to figure this out?

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

Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 11:39

Message:
Maybe not kill it, but make it a configuration option?  Also, I think this is the 
reason that my specs were failing last night concerning the inclusion of the 
module, bug #15637.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-15 09:58

Message:
I'd sooner kill the feature. That sort of subtlety would make things very confusing.

In my view, the feature is either in or out.

Thoughts?

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

Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 02:46

Message:
Would it be possible to only do this for public methods, and exclude protected 
ones?

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

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

Message:
That's actually by design. In an effort to play well with others, we're working towards a world in which people who prefer to use classes and methods can do this:

class FooSpec < Spec::ExampleGroup
  def should_bar
    ...
  end
end

This works just like Test::Unit except it looks for methods that start with "should" instead of "test". This means that you can not have helper methods that start with "should".

I'm going to leave this ticket open and would welcome opinions on this.

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

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

From noreply at rubyforge.org  Thu Nov 15 14:57:06 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 15 Nov 2007 14:57:06 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15638 ] When naming a protected method,
	if it begins with 'should_' it causes it to be treated as an
	example.
Message-ID: <20071115195706.B26EB18585CA@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Nathan Sutton (fowlduck)
Assigned to: Nobody (None)
Summary: When naming a protected method, if it begins with 'should_' it causes it to be treated as an example.

Initial Comment:
starting a protected method with should_ causes it to be treated as an example.

edge rails revision: 8146
edge rspec revision: 2889
edge rspec_on_rails revision: 2889

describe SessionsController do

  # a bunch of examples, some that call should_be_logged_in

protected

  def should_be_logged_in
    response.session.should_not be_nil
    session[:user].should_not be_nil
  end

end

When running the spec:

SessionsController should_be_logged_in' FAILED
expected not nil, got nil
./spec/controllers/sessions_controller_spec.rb:111:in `should_be_logged_in'
script/spec:4:


Renamed the method to 'be_logged_in' and all specs then pass.  Line 111, in this case, is 'session[:user].should_not be_nil'.



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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-15 19:57

Message:
It's not only a matter of a pit-stop. It's that some people would prefer to stay in class/method land and use this format from day one and keep it that way:

class FooSpec < Spec::ExampleGroup
  def should_bar
    ...
  end
end

My opinion is that this is a reasonable request and that there's no reason not to offer it - except for this conflict with helpers that start w/ should.

You can't start helpers with test in test unit, I don't see why this should be a big deal.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-11-15 19:50

Message:
I think we should kill the feature. test_ methods and it blocks is enough. I don't think we need another pit stop in between.

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

Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 16:51

Message:
This is the cause of bug #15637 and the subtlety of it will cause breakage for 
those who don't expect it.  How long did we spend trying to figure this out?

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

Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 16:39

Message:
Maybe not kill it, but make it a configuration option?  Also, I think this is the 
reason that my specs were failing last night concerning the inclusion of the 
module, bug #15637.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-15 14:58

Message:
I'd sooner kill the feature. That sort of subtlety would make things very confusing.

In my view, the feature is either in or out.

Thoughts?

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

Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 07:46

Message:
Would it be possible to only do this for public methods, and exclude protected 
ones?

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

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

Message:
That's actually by design. In an effort to play well with others, we're working towards a world in which people who prefer to use classes and methods can do this:

class FooSpec < Spec::ExampleGroup
  def should_bar
    ...
  end
end

This works just like Test::Unit except it looks for methods that start with "should" instead of "test". This means that you can not have helper methods that start with "should".

I'm going to leave this ticket open and would welcome opinions on this.

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

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

From noreply at rubyforge.org  Thu Nov 15 15:02:12 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 15 Nov 2007 15:02:12 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15638 ] When naming a protected method,
	if it begins with 'should_' it causes it to be treated as an
	example.
Message-ID: <20071115200212.73AD41598061@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Nathan Sutton (fowlduck)
Assigned to: Nobody (None)
Summary: When naming a protected method, if it begins with 'should_' it causes it to be treated as an example.

Initial Comment:
starting a protected method with should_ causes it to be treated as an example.

edge rails revision: 8146
edge rspec revision: 2889
edge rspec_on_rails revision: 2889

describe SessionsController do

  # a bunch of examples, some that call should_be_logged_in

protected

  def should_be_logged_in
    response.session.should_not be_nil
    session[:user].should_not be_nil
  end

end

When running the spec:

SessionsController should_be_logged_in' FAILED
expected not nil, got nil
./spec/controllers/sessions_controller_spec.rb:111:in `should_be_logged_in'
script/spec:4:


Renamed the method to 'be_logged_in' and all specs then pass.  Line 111, in this case, is 'session[:user].should_not be_nil'.



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

>Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 14:02

Message:
Well, I'm using methods starting with should to group examples for a specific 
purpose.  If there was a way to do this and re-use them then I wouldn't be doing 
this in the first place.  I would use shared behaviors but you can't pass values 
into them.  Maybe the solution is not to remove this, but to define a way to 
accomplish what I was trying to do, one that won't get stomped on.


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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-15 13:57

Message:
It's not only a matter of a pit-stop. It's that some people would prefer to stay in class/method land and use this format from day one and keep it that way:

class FooSpec < Spec::ExampleGroup
  def should_bar
    ...
  end
end

My opinion is that this is a reasonable request and that there's no reason not to offer it - except for this conflict with helpers that start w/ should.

You can't start helpers with test in test unit, I don't see why this should be a big deal.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-11-15 13:50

Message:
I think we should kill the feature. test_ methods and it blocks is enough. I don't think we need another pit stop in between.

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

Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 10:51

Message:
This is the cause of bug #15637 and the subtlety of it will cause breakage for 
those who don't expect it.  How long did we spend trying to figure this out?

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

Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 10:39

Message:
Maybe not kill it, but make it a configuration option?  Also, I think this is the 
reason that my specs were failing last night concerning the inclusion of the 
module, bug #15637.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-15 08:58

Message:
I'd sooner kill the feature. That sort of subtlety would make things very confusing.

In my view, the feature is either in or out.

Thoughts?

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

Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 01:46

Message:
Would it be possible to only do this for public methods, and exclude protected 
ones?

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-15 01:44

Message:
That's actually by design. In an effort to play well with others, we're working towards a world in which people who prefer to use classes and methods can do this:

class FooSpec < Spec::ExampleGroup
  def should_bar
    ...
  end
end

This works just like Test::Unit except it looks for methods that start with "should" instead of "test". This means that you can not have helper methods that start with "should".

I'm going to leave this ticket open and would welcome opinions on this.

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

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

From noreply at rubyforge.org  Thu Nov 15 15:14:17 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 15 Nov 2007 15:14:17 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15638 ] When naming a protected method,
	if it begins with 'should_' it causes it to be treated as an
	example.
Message-ID: <20071115201417.EE4E018585CE@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Nathan Sutton (fowlduck)
Assigned to: Nobody (None)
Summary: When naming a protected method, if it begins with 'should_' it causes it to be treated as an example.

Initial Comment:
starting a protected method with should_ causes it to be treated as an example.

edge rails revision: 8146
edge rspec revision: 2889
edge rspec_on_rails revision: 2889

describe SessionsController do

  # a bunch of examples, some that call should_be_logged_in

protected

  def should_be_logged_in
    response.session.should_not be_nil
    session[:user].should_not be_nil
  end

end

When running the spec:

SessionsController should_be_logged_in' FAILED
expected not nil, got nil
./spec/controllers/sessions_controller_spec.rb:111:in `should_be_logged_in'
script/spec:4:


Renamed the method to 'be_logged_in' and all specs then pass.  Line 111, in this case, is 'session[:user].should_not be_nil'.



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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-11-15 20:14

Message:
I don't quite understand this thread.  Who is actually using should_... ?

I know some people are using test "here is a description of something to test", and some people are using should "do something or other", but who is using should_do_something_or_other?



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

Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 20:02

Message:
Well, I'm using methods starting with should to group examples for a specific 
purpose.  If there was a way to do this and re-use them then I wouldn't be doing 
this in the first place.  I would use shared behaviors but you can't pass values 
into them.  Maybe the solution is not to remove this, but to define a way to 
accomplish what I was trying to do, one that won't get stomped on.


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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-15 19:57

Message:
It's not only a matter of a pit-stop. It's that some people would prefer to stay in class/method land and use this format from day one and keep it that way:

class FooSpec < Spec::ExampleGroup
  def should_bar
    ...
  end
end

My opinion is that this is a reasonable request and that there's no reason not to offer it - except for this conflict with helpers that start w/ should.

You can't start helpers with test in test unit, I don't see why this should be a big deal.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-11-15 19:50

Message:
I think we should kill the feature. test_ methods and it blocks is enough. I don't think we need another pit stop in between.

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

Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 16:51

Message:
This is the cause of bug #15637 and the subtlety of it will cause breakage for 
those who don't expect it.  How long did we spend trying to figure this out?

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

Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 16:39

Message:
Maybe not kill it, but make it a configuration option?  Also, I think this is the 
reason that my specs were failing last night concerning the inclusion of the 
module, bug #15637.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-15 14:58

Message:
I'd sooner kill the feature. That sort of subtlety would make things very confusing.

In my view, the feature is either in or out.

Thoughts?

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

Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 07:46

Message:
Would it be possible to only do this for public methods, and exclude protected 
ones?

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

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

Message:
That's actually by design. In an effort to play well with others, we're working towards a world in which people who prefer to use classes and methods can do this:

class FooSpec < Spec::ExampleGroup
  def should_bar
    ...
  end
end

This works just like Test::Unit except it looks for methods that start with "should" instead of "test". This means that you can not have helper methods that start with "should".

I'm going to leave this ticket open and would welcome opinions on this.

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

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

From noreply at rubyforge.org  Thu Nov 15 15:16:12 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 15 Nov 2007 15:16:12 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15638 ] When naming a protected method,
	if it begins with 'should_' it causes it to be treated as an
	example.
Message-ID: <20071115201612.4841C18585CF@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Nathan Sutton (fowlduck)
Assigned to: Nobody (None)
Summary: When naming a protected method, if it begins with 'should_' it causes it to be treated as an example.

Initial Comment:
starting a protected method with should_ causes it to be treated as an example.

edge rails revision: 8146
edge rspec revision: 2889
edge rspec_on_rails revision: 2889

describe SessionsController do

  # a bunch of examples, some that call should_be_logged_in

protected

  def should_be_logged_in
    response.session.should_not be_nil
    session[:user].should_not be_nil
  end

end

When running the spec:

SessionsController should_be_logged_in' FAILED
expected not nil, got nil
./spec/controllers/sessions_controller_spec.rb:111:in `should_be_logged_in'
script/spec:4:


Renamed the method to 'be_logged_in' and all specs then pass.  Line 111, in this case, is 'session[:user].should_not be_nil'.



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

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

Message:
Scott - nobody is using it yet because nobody really knows about it yet - it's all in trunk and experimental - but is the result of several conversations I had w/ RubyConf attendees.

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-11-15 20:14

Message:
I don't quite understand this thread.  Who is actually using should_... ?

I know some people are using test "here is a description of something to test", and some people are using should "do something or other", but who is using should_do_something_or_other?



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

Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 20:02

Message:
Well, I'm using methods starting with should to group examples for a specific 
purpose.  If there was a way to do this and re-use them then I wouldn't be doing 
this in the first place.  I would use shared behaviors but you can't pass values 
into them.  Maybe the solution is not to remove this, but to define a way to 
accomplish what I was trying to do, one that won't get stomped on.


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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-15 19:57

Message:
It's not only a matter of a pit-stop. It's that some people would prefer to stay in class/method land and use this format from day one and keep it that way:

class FooSpec < Spec::ExampleGroup
  def should_bar
    ...
  end
end

My opinion is that this is a reasonable request and that there's no reason not to offer it - except for this conflict with helpers that start w/ should.

You can't start helpers with test in test unit, I don't see why this should be a big deal.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-11-15 19:50

Message:
I think we should kill the feature. test_ methods and it blocks is enough. I don't think we need another pit stop in between.

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

Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 16:51

Message:
This is the cause of bug #15637 and the subtlety of it will cause breakage for 
those who don't expect it.  How long did we spend trying to figure this out?

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

Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 16:39

Message:
Maybe not kill it, but make it a configuration option?  Also, I think this is the 
reason that my specs were failing last night concerning the inclusion of the 
module, bug #15637.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-15 14:58

Message:
I'd sooner kill the feature. That sort of subtlety would make things very confusing.

In my view, the feature is either in or out.

Thoughts?

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

Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 07:46

Message:
Would it be possible to only do this for public methods, and exclude protected 
ones?

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

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

Message:
That's actually by design. In an effort to play well with others, we're working towards a world in which people who prefer to use classes and methods can do this:

class FooSpec < Spec::ExampleGroup
  def should_bar
    ...
  end
end

This works just like Test::Unit except it looks for methods that start with "should" instead of "test". This means that you can not have helper methods that start with "should".

I'm going to leave this ticket open and would welcome opinions on this.

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

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

From noreply at rubyforge.org  Thu Nov 15 15:17:06 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 15 Nov 2007 15:17:06 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15638 ] When naming a protected method,
	if it begins with 'should_' it causes it to be treated as an
	example.
Message-ID: <20071115201706.D7C4C18585CF@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Nathan Sutton (fowlduck)
Assigned to: Nobody (None)
Summary: When naming a protected method, if it begins with 'should_' it causes it to be treated as an example.

Initial Comment:
starting a protected method with should_ causes it to be treated as an example.

edge rails revision: 8146
edge rspec revision: 2889
edge rspec_on_rails revision: 2889

describe SessionsController do

  # a bunch of examples, some that call should_be_logged_in

protected

  def should_be_logged_in
    response.session.should_not be_nil
    session[:user].should_not be_nil
  end

end

When running the spec:

SessionsController should_be_logged_in' FAILED
expected not nil, got nil
./spec/controllers/sessions_controller_spec.rb:111:in `should_be_logged_in'
script/spec:4:


Renamed the method to 'be_logged_in' and all specs then pass.  Line 111, in this case, is 'session[:user].should_not be_nil'.



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

>Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 14:17

Message:
In my case, I was using a protected method to do "should_be_logged_in", which 
just does a couple expectations.  RSpec was interpreting it as a spec and 
running it as one, which of course made it fail.

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

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

Message:
Scott - nobody is using it yet because nobody really knows about it yet - it's all in trunk and experimental - but is the result of several conversations I had w/ RubyConf attendees.

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-11-15 14:14

Message:
I don't quite understand this thread.  Who is actually using should_... ?

I know some people are using test "here is a description of something to test", and some people are using should "do something or other", but who is using should_do_something_or_other?



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

Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 14:02

Message:
Well, I'm using methods starting with should to group examples for a specific 
purpose.  If there was a way to do this and re-use them then I wouldn't be doing 
this in the first place.  I would use shared behaviors but you can't pass values 
into them.  Maybe the solution is not to remove this, but to define a way to 
accomplish what I was trying to do, one that won't get stomped on.


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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-15 13:57

Message:
It's not only a matter of a pit-stop. It's that some people would prefer to stay in class/method land and use this format from day one and keep it that way:

class FooSpec < Spec::ExampleGroup
  def should_bar
    ...
  end
end

My opinion is that this is a reasonable request and that there's no reason not to offer it - except for this conflict with helpers that start w/ should.

You can't start helpers with test in test unit, I don't see why this should be a big deal.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-11-15 13:50

Message:
I think we should kill the feature. test_ methods and it blocks is enough. I don't think we need another pit stop in between.

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

Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 10:51

Message:
This is the cause of bug #15637 and the subtlety of it will cause breakage for 
those who don't expect it.  How long did we spend trying to figure this out?

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

Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 10:39

Message:
Maybe not kill it, but make it a configuration option?  Also, I think this is the 
reason that my specs were failing last night concerning the inclusion of the 
module, bug #15637.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-15 08:58

Message:
I'd sooner kill the feature. That sort of subtlety would make things very confusing.

In my view, the feature is either in or out.

Thoughts?

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

Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 01:46

Message:
Would it be possible to only do this for public methods, and exclude protected 
ones?

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-15 01:44

Message:
That's actually by design. In an effort to play well with others, we're working towards a world in which people who prefer to use classes and methods can do this:

class FooSpec < Spec::ExampleGroup
  def should_bar
    ...
  end
end

This works just like Test::Unit except it looks for methods that start with "should" instead of "test". This means that you can not have helper methods that start with "should".

I'm going to leave this ticket open and would welcome opinions on this.

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

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

From noreply at rubyforge.org  Thu Nov 15 15:17:32 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 15 Nov 2007 15:17:32 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15638 ] When naming a protected method,
	if it begins with 'should_' it causes it to be treated as an
	example.
Message-ID: <20071115201732.6926E18585D3@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Nathan Sutton (fowlduck)
Assigned to: Nobody (None)
Summary: When naming a protected method, if it begins with 'should_' it causes it to be treated as an example.

Initial Comment:
starting a protected method with should_ causes it to be treated as an example.

edge rails revision: 8146
edge rspec revision: 2889
edge rspec_on_rails revision: 2889

describe SessionsController do

  # a bunch of examples, some that call should_be_logged_in

protected

  def should_be_logged_in
    response.session.should_not be_nil
    session[:user].should_not be_nil
  end

end

When running the spec:

SessionsController should_be_logged_in' FAILED
expected not nil, got nil
./spec/controllers/sessions_controller_spec.rb:111:in `should_be_logged_in'
script/spec:4:


Renamed the method to 'be_logged_in' and all specs then pass.  Line 111, in this case, is 'session[:user].should_not be_nil'.



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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-15 20:17

Message:
Nathan: I agree - there should be a better API for helper methods and sharing. We likely won't get there for this release, but it is on the radar.

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

Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 20:17

Message:
In my case, I was using a protected method to do "should_be_logged_in", which 
just does a couple expectations.  RSpec was interpreting it as a spec and 
running it as one, which of course made it fail.

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

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

Message:
Scott - nobody is using it yet because nobody really knows about it yet - it's all in trunk and experimental - but is the result of several conversations I had w/ RubyConf attendees.

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-11-15 20:14

Message:
I don't quite understand this thread.  Who is actually using should_... ?

I know some people are using test "here is a description of something to test", and some people are using should "do something or other", but who is using should_do_something_or_other?



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

Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 20:02

Message:
Well, I'm using methods starting with should to group examples for a specific 
purpose.  If there was a way to do this and re-use them then I wouldn't be doing 
this in the first place.  I would use shared behaviors but you can't pass values 
into them.  Maybe the solution is not to remove this, but to define a way to 
accomplish what I was trying to do, one that won't get stomped on.


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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-15 19:57

Message:
It's not only a matter of a pit-stop. It's that some people would prefer to stay in class/method land and use this format from day one and keep it that way:

class FooSpec < Spec::ExampleGroup
  def should_bar
    ...
  end
end

My opinion is that this is a reasonable request and that there's no reason not to offer it - except for this conflict with helpers that start w/ should.

You can't start helpers with test in test unit, I don't see why this should be a big deal.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-11-15 19:50

Message:
I think we should kill the feature. test_ methods and it blocks is enough. I don't think we need another pit stop in between.

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

Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 16:51

Message:
This is the cause of bug #15637 and the subtlety of it will cause breakage for 
those who don't expect it.  How long did we spend trying to figure this out?

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

Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 16:39

Message:
Maybe not kill it, but make it a configuration option?  Also, I think this is the 
reason that my specs were failing last night concerning the inclusion of the 
module, bug #15637.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-15 14:58

Message:
I'd sooner kill the feature. That sort of subtlety would make things very confusing.

In my view, the feature is either in or out.

Thoughts?

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

Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 07:46

Message:
Would it be possible to only do this for public methods, and exclude protected 
ones?

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

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

Message:
That's actually by design. In an effort to play well with others, we're working towards a world in which people who prefer to use classes and methods can do this:

class FooSpec < Spec::ExampleGroup
  def should_bar
    ...
  end
end

This works just like Test::Unit except it looks for methods that start with "should" instead of "test". This means that you can not have helper methods that start with "should".

I'm going to leave this ticket open and would welcome opinions on this.

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

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

From noreply at rubyforge.org  Thu Nov 15 15:32:01 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 15 Nov 2007 15:32:01 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15638 ] When naming a protected method,
	if it begins with 'should_' it causes it to be treated as an
	example.
Message-ID: <20071115203201.3A98218585C2@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Nathan Sutton (fowlduck)
Assigned to: Nobody (None)
Summary: When naming a protected method, if it begins with 'should_' it causes it to be treated as an example.

Initial Comment:
starting a protected method with should_ causes it to be treated as an example.

edge rails revision: 8146
edge rspec revision: 2889
edge rspec_on_rails revision: 2889

describe SessionsController do

  # a bunch of examples, some that call should_be_logged_in

protected

  def should_be_logged_in
    response.session.should_not be_nil
    session[:user].should_not be_nil
  end

end

When running the spec:

SessionsController should_be_logged_in' FAILED
expected not nil, got nil
./spec/controllers/sessions_controller_spec.rb:111:in `should_be_logged_in'
script/spec:4:


Renamed the method to 'be_logged_in' and all specs then pass.  Line 111, in this case, is 'session[:user].should_not be_nil'.



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

>Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 14:32

Message:
We have it, shared behaviors, it just doesn't take parameters.  If it did, and 
maybe even a proc, you could do a LOT.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-15 14:17

Message:
Nathan: I agree - there should be a better API for helper methods and sharing. We likely won't get there for this release, but it is on the radar.

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

Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 14:17

Message:
In my case, I was using a protected method to do "should_be_logged_in", which 
just does a couple expectations.  RSpec was interpreting it as a spec and 
running it as one, which of course made it fail.

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

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

Message:
Scott - nobody is using it yet because nobody really knows about it yet - it's all in trunk and experimental - but is the result of several conversations I had w/ RubyConf attendees.

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-11-15 14:14

Message:
I don't quite understand this thread.  Who is actually using should_... ?

I know some people are using test "here is a description of something to test", and some people are using should "do something or other", but who is using should_do_something_or_other?



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

Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 14:02

Message:
Well, I'm using methods starting with should to group examples for a specific 
purpose.  If there was a way to do this and re-use them then I wouldn't be doing 
this in the first place.  I would use shared behaviors but you can't pass values 
into them.  Maybe the solution is not to remove this, but to define a way to 
accomplish what I was trying to do, one that won't get stomped on.


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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-15 13:57

Message:
It's not only a matter of a pit-stop. It's that some people would prefer to stay in class/method land and use this format from day one and keep it that way:

class FooSpec < Spec::ExampleGroup
  def should_bar
    ...
  end
end

My opinion is that this is a reasonable request and that there's no reason not to offer it - except for this conflict with helpers that start w/ should.

You can't start helpers with test in test unit, I don't see why this should be a big deal.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-11-15 13:50

Message:
I think we should kill the feature. test_ methods and it blocks is enough. I don't think we need another pit stop in between.

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

Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 10:51

Message:
This is the cause of bug #15637 and the subtlety of it will cause breakage for 
those who don't expect it.  How long did we spend trying to figure this out?

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

Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 10:39

Message:
Maybe not kill it, but make it a configuration option?  Also, I think this is the 
reason that my specs were failing last night concerning the inclusion of the 
module, bug #15637.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-15 08:58

Message:
I'd sooner kill the feature. That sort of subtlety would make things very confusing.

In my view, the feature is either in or out.

Thoughts?

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

Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 01:46

Message:
Would it be possible to only do this for public methods, and exclude protected 
ones?

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-15 01:44

Message:
That's actually by design. In an effort to play well with others, we're working towards a world in which people who prefer to use classes and methods can do this:

class FooSpec < Spec::ExampleGroup
  def should_bar
    ...
  end
end

This works just like Test::Unit except it looks for methods that start with "should" instead of "test". This means that you can not have helper methods that start with "should".

I'm going to leave this ticket open and would welcome opinions on this.

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

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

From noreply at rubyforge.org  Thu Nov 15 17:50:17 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 15 Nov 2007 17:50:17 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15659 ] GivenScenario fails when it is a
	RailsStory
Message-ID: <20071115225018.0658A1598060@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Nathan Sutton (fowlduck)
Assigned to: Nobody (None)
Summary: GivenScenario fails when it is a RailsStory

Initial Comment:
Given the following code:
require File.dirname(__FILE__) + "/helper"

Story "Checkin out the lil buggles", %Q{
  As a user of rspec
  I want to check out the lil buggles
  So that I can run rails stories
}, :type => RailsStory do
  Scenario "We have one scenario" do
    Given "a scenario"
    When "it is run"
    Then "it should be ok"
  end
    
  Scenario "We have a second scenario" do
    GivenScenario "We have one scenario"
    When "it is run again"
    Then "it should bork"
  end
end



And it is run:

$ ruby stories/test.story 
Running 2 scenarios:

Story: Checkin out the lil buggles

  
    As a user of rspec
    I want to check out the lil buggles
    So that I can run rails stories


Scenario: We have one scenario

  Given a scenario (PENDING)

  When it is run (PENDING)

  Then it should be ok (PENDING)

/Users/nate/Code/sevenwire/rediswhite/repository/trunk/vendor/plugins/rspec/lib/spec/story/world.rb:48:in `perform': wrong number of arguments (2 for 1) (ArgumentError)
	from /Users/nate/Code/sevenwire/rediswhite/repository/trunk/vendor/plugins/rspec/lib/spec/story/world.rb:48:in `run_given_scenario_with_suspended_listeners'
	from /Users/nate/Code/sevenwire/rediswhite/repository/trunk/vendor/plugins/rspec/lib/spec/story/world.rb:87:in `GivenScenario'
	from stories/test.story:15
	from /Users/nate/Code/sevenwire/rediswhite/repository/trunk/vendor/plugins/rspec/lib/spec/story/runner/scenario_runner.rb:14:in `instance_eval'
	from /Users/nate/Code/sevenwire/rediswhite/repository/trunk/vendor/plugins/rspec/lib/spec/story/runner/scenario_runner.rb:14:in `run'
	from /Users/nate/Code/sevenwire/rediswhite/repository/trunk/vendor/plugins/rspec/lib/spec/story/runner/story_runner.rb:48:in `run_stories'
	from /Users/nate/Code/sevenwire/rediswhite/repository/trunk/vendor/plugins/rspec/lib/spec/story/runner/story_runner.rb:44:in `each'
	from /Users/nate/Code/sevenwire/rediswhite/repository/trunk/vendor/plugins/rspec/lib/spec/story/runner/story_runner.rb:44:in `run_stories'
	from /Users/nate/Code/sevenwire/rediswhite/repository/trunk/vendor/plugins/rspec/lib/spec/story/runner/story_runner.rb:39:in `each'
	from /Users/nate/Code/sevenwire/rediswhite/repository/trunk/vendor/plugins/rspec/lib/spec/story/runner/story_runner.rb:39:in `run_stories'
	from /Users/nate/Code/sevenwire/rediswhite/repository/trunk/vendor/plugins/rspec/lib/spec/story/runner.rb:49:in `register_exit_hook'
	from stories/test.story:3
Scenario: We have a second scenario





It is an issue with Spec::Story::GivenScenario#perform in rspec_on_rails/lib/spec/rails/story_adapter.rb on line 42.  It expects it to take a second argument like GivenScenario does elsewhere.  

I have attached a patch, I think I did it right.

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

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

From noreply at rubyforge.org  Thu Nov 15 17:51:03 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 15 Nov 2007 17:51:03 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15659 ] GivenScenario fails when it is a
	RailsStory
Message-ID: <20071115225104.0500418585E2@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Nathan Sutton (fowlduck)
Assigned to: Nobody (None)
Summary: GivenScenario fails when it is a RailsStory

Initial Comment:
Given the following code:
require File.dirname(__FILE__) + "/helper"

Story "Checkin out the lil buggles", %Q{
  As a user of rspec
  I want to check out the lil buggles
  So that I can run rails stories
}, :type => RailsStory do
  Scenario "We have one scenario" do
    Given "a scenario"
    When "it is run"
    Then "it should be ok"
  end
    
  Scenario "We have a second scenario" do
    GivenScenario "We have one scenario"
    When "it is run again"
    Then "it should bork"
  end
end



And it is run:

$ ruby stories/test.story 
Running 2 scenarios:

Story: Checkin out the lil buggles

  
    As a user of rspec
    I want to check out the lil buggles
    So that I can run rails stories


Scenario: We have one scenario

  Given a scenario (PENDING)

  When it is run (PENDING)

  Then it should be ok (PENDING)

/Users/nate/Code/sevenwire/rediswhite/repository/trunk/vendor/plugins/rspec/lib/spec/story/world.rb:48:in `perform': wrong number of arguments (2 for 1) (ArgumentError)
	from /Users/nate/Code/sevenwire/rediswhite/repository/trunk/vendor/plugins/rspec/lib/spec/story/world.rb:48:in `run_given_scenario_with_suspended_listeners'
	from /Users/nate/Code/sevenwire/rediswhite/repository/trunk/vendor/plugins/rspec/lib/spec/story/world.rb:87:in `GivenScenario'
	from stories/test.story:15
	from /Users/nate/Code/sevenwire/rediswhite/repository/trunk/vendor/plugins/rspec/lib/spec/story/runner/scenario_runner.rb:14:in `instance_eval'
	from /Users/nate/Code/sevenwire/rediswhite/repository/trunk/vendor/plugins/rspec/lib/spec/story/runner/scenario_runner.rb:14:in `run'
	from /Users/nate/Code/sevenwire/rediswhite/repository/trunk/vendor/plugins/rspec/lib/spec/story/runner/story_runner.rb:48:in `run_stories'
	from /Users/nate/Code/sevenwire/rediswhite/repository/trunk/vendor/plugins/rspec/lib/spec/story/runner/story_runner.rb:44:in `each'
	from /Users/nate/Code/sevenwire/rediswhite/repository/trunk/vendor/plugins/rspec/lib/spec/story/runner/story_runner.rb:44:in `run_stories'
	from /Users/nate/Code/sevenwire/rediswhite/repository/trunk/vendor/plugins/rspec/lib/spec/story/runner/story_runner.rb:39:in `each'
	from /Users/nate/Code/sevenwire/rediswhite/repository/trunk/vendor/plugins/rspec/lib/spec/story/runner/story_runner.rb:39:in `run_stories'
	from /Users/nate/Code/sevenwire/rediswhite/repository/trunk/vendor/plugins/rspec/lib/spec/story/runner.rb:49:in `register_exit_hook'
	from stories/test.story:3
Scenario: We have a second scenario





It is an issue with Spec::Story::GivenScenario#perform in rspec_on_rails/lib/spec/rails/story_adapter.rb on line 42.  It expects it to take a second argument like GivenScenario does elsewhere.  

I have attached a patch, I think I did it right.

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

>Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 16:51

Message:
forgot to note:
rspec edge revision 2894
rspec_on_rails edge revision 2894
rails edge revision 8146


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

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

From noreply at rubyforge.org  Thu Nov 15 18:06:42 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 15 Nov 2007 18:06:42 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15659 ] GivenScenario fails when it is a
	RailsStory
Message-ID: <20071115230642.7875E16780E7@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Nathan Sutton (fowlduck)
Assigned to: Nobody (None)
Summary: GivenScenario fails when it is a RailsStory

Initial Comment:
Given the following code:
require File.dirname(__FILE__) + "/helper"

Story "Checkin out the lil buggles", %Q{
  As a user of rspec
  I want to check out the lil buggles
  So that I can run rails stories
}, :type => RailsStory do
  Scenario "We have one scenario" do
    Given "a scenario"
    When "it is run"
    Then "it should be ok"
  end
    
  Scenario "We have a second scenario" do
    GivenScenario "We have one scenario"
    When "it is run again"
    Then "it should bork"
  end
end



And it is run:

$ ruby stories/test.story 
Running 2 scenarios:

Story: Checkin out the lil buggles

  
    As a user of rspec
    I want to check out the lil buggles
    So that I can run rails stories


Scenario: We have one scenario

  Given a scenario (PENDING)

  When it is run (PENDING)

  Then it should be ok (PENDING)

/Users/nate/Code/sevenwire/rediswhite/repository/trunk/vendor/plugins/rspec/lib/spec/story/world.rb:48:in `perform': wrong number of arguments (2 for 1) (ArgumentError)
	from /Users/nate/Code/sevenwire/rediswhite/repository/trunk/vendor/plugins/rspec/lib/spec/story/world.rb:48:in `run_given_scenario_with_suspended_listeners'
	from /Users/nate/Code/sevenwire/rediswhite/repository/trunk/vendor/plugins/rspec/lib/spec/story/world.rb:87:in `GivenScenario'
	from stories/test.story:15
	from /Users/nate/Code/sevenwire/rediswhite/repository/trunk/vendor/plugins/rspec/lib/spec/story/runner/scenario_runner.rb:14:in `instance_eval'
	from /Users/nate/Code/sevenwire/rediswhite/repository/trunk/vendor/plugins/rspec/lib/spec/story/runner/scenario_runner.rb:14:in `run'
	from /Users/nate/Code/sevenwire/rediswhite/repository/trunk/vendor/plugins/rspec/lib/spec/story/runner/story_runner.rb:48:in `run_stories'
	from /Users/nate/Code/sevenwire/rediswhite/repository/trunk/vendor/plugins/rspec/lib/spec/story/runner/story_runner.rb:44:in `each'
	from /Users/nate/Code/sevenwire/rediswhite/repository/trunk/vendor/plugins/rspec/lib/spec/story/runner/story_runner.rb:44:in `run_stories'
	from /Users/nate/Code/sevenwire/rediswhite/repository/trunk/vendor/plugins/rspec/lib/spec/story/runner/story_runner.rb:39:in `each'
	from /Users/nate/Code/sevenwire/rediswhite/repository/trunk/vendor/plugins/rspec/lib/spec/story/runner/story_runner.rb:39:in `run_stories'
	from /Users/nate/Code/sevenwire/rediswhite/repository/trunk/vendor/plugins/rspec/lib/spec/story/runner.rb:49:in `register_exit_hook'
	from stories/test.story:3
Scenario: We have a second scenario





It is an issue with Spec::Story::GivenScenario#perform in rspec_on_rails/lib/spec/rails/story_adapter.rb on line 42.  It expects it to take a second argument like GivenScenario does elsewhere.  

I have attached a patch, I think I did it right.

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

>Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 17:06

Message:
Oh, and with that change I get this output:

$ ruby stories/test.story 
Running 2 scenarios:

Story: Checkin out the lil buggles

  
    As a user of rspec
    I want to check out the lil buggles
    So that I can run rails stories


Scenario: We have one scenario

  Given a scenario (PENDING)

  When it is run (PENDING)

  Then it should be ok (PENDING)

Scenario: We have a second scenario

  When it is run again (PENDING)

  Then it should bork (PENDING)



2 scenarios: 0 succeeded, 0 failed, 2 pending

Pending Steps:
1) Checkin out the lil buggles (We have one scenario): Unimplemented step: a 
scenario
2) Checkin out the lil buggles (We have one scenario): Unimplemented step: it 
is run
3) Checkin out the lil buggles (We have one scenario): Unimplemented step: it 
should be ok
4) Checkin out the lil buggles (We have a second scenario): Unimplemented 
step: a scenario
5) Checkin out the lil buggles (We have a second scenario): Unimplemented 
step: it is run
6) Checkin out the lil buggles (We have a second scenario): Unimplemented 
step: it should be ok
7) Checkin out the lil buggles (We have a second scenario): Unimplemented 
step: it is run again
8) Checkin out the lil buggles (We have a second scenario): Unimplemented 
step: it should bork



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

Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 16:51

Message:
forgot to note:
rspec edge revision 2894
rspec_on_rails edge revision 2894
rails edge revision 8146


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

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

From noreply at rubyforge.org  Fri Nov 16 00:20:40 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 16 Nov 2007 00:20:40 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15659 ] GivenScenario fails when it is a
	RailsStory
Message-ID: <20071116052040.41A361598060@rubyforge.org>

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

Category: rails plugin
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Nathan Sutton (fowlduck)
Assigned to: Nobody (None)
Summary: GivenScenario fails when it is a RailsStory

Initial Comment:
Given the following code:
require File.dirname(__FILE__) + "/helper"

Story "Checkin out the lil buggles", %Q{
  As a user of rspec
  I want to check out the lil buggles
  So that I can run rails stories
}, :type => RailsStory do
  Scenario "We have one scenario" do
    Given "a scenario"
    When "it is run"
    Then "it should be ok"
  end
    
  Scenario "We have a second scenario" do
    GivenScenario "We have one scenario"
    When "it is run again"
    Then "it should bork"
  end
end



And it is run:

$ ruby stories/test.story 
Running 2 scenarios:

Story: Checkin out the lil buggles

  
    As a user of rspec
    I want to check out the lil buggles
    So that I can run rails stories


Scenario: We have one scenario

  Given a scenario (PENDING)

  When it is run (PENDING)

  Then it should be ok (PENDING)

/Users/nate/Code/sevenwire/rediswhite/repository/trunk/vendor/plugins/rspec/lib/spec/story/world.rb:48:in `perform': wrong number of arguments (2 for 1) (ArgumentError)
	from /Users/nate/Code/sevenwire/rediswhite/repository/trunk/vendor/plugins/rspec/lib/spec/story/world.rb:48:in `run_given_scenario_with_suspended_listeners'
	from /Users/nate/Code/sevenwire/rediswhite/repository/trunk/vendor/plugins/rspec/lib/spec/story/world.rb:87:in `GivenScenario'
	from stories/test.story:15
	from /Users/nate/Code/sevenwire/rediswhite/repository/trunk/vendor/plugins/rspec/lib/spec/story/runner/scenario_runner.rb:14:in `instance_eval'
	from /Users/nate/Code/sevenwire/rediswhite/repository/trunk/vendor/plugins/rspec/lib/spec/story/runner/scenario_runner.rb:14:in `run'
	from /Users/nate/Code/sevenwire/rediswhite/repository/trunk/vendor/plugins/rspec/lib/spec/story/runner/story_runner.rb:48:in `run_stories'
	from /Users/nate/Code/sevenwire/rediswhite/repository/trunk/vendor/plugins/rspec/lib/spec/story/runner/story_runner.rb:44:in `each'
	from /Users/nate/Code/sevenwire/rediswhite/repository/trunk/vendor/plugins/rspec/lib/spec/story/runner/story_runner.rb:44:in `run_stories'
	from /Users/nate/Code/sevenwire/rediswhite/repository/trunk/vendor/plugins/rspec/lib/spec/story/runner/story_runner.rb:39:in `each'
	from /Users/nate/Code/sevenwire/rediswhite/repository/trunk/vendor/plugins/rspec/lib/spec/story/runner/story_runner.rb:39:in `run_stories'
	from /Users/nate/Code/sevenwire/rediswhite/repository/trunk/vendor/plugins/rspec/lib/spec/story/runner.rb:49:in `register_exit_hook'
	from stories/test.story:3
Scenario: We have a second scenario





It is an issue with Spec::Story::GivenScenario#perform in rspec_on_rails/lib/spec/rails/story_adapter.rb on line 42.  It expects it to take a second argument like GivenScenario does elsewhere.  

I have attached a patch, I think I did it right.

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

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

Message:
Applied to r2899

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

Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 23:06

Message:
Oh, and with that change I get this output:

$ ruby stories/test.story 
Running 2 scenarios:

Story: Checkin out the lil buggles

  
    As a user of rspec
    I want to check out the lil buggles
    So that I can run rails stories


Scenario: We have one scenario

  Given a scenario (PENDING)

  When it is run (PENDING)

  Then it should be ok (PENDING)

Scenario: We have a second scenario

  When it is run again (PENDING)

  Then it should bork (PENDING)



2 scenarios: 0 succeeded, 0 failed, 2 pending

Pending Steps:
1) Checkin out the lil buggles (We have one scenario): Unimplemented step: a 
scenario
2) Checkin out the lil buggles (We have one scenario): Unimplemented step: it 
is run
3) Checkin out the lil buggles (We have one scenario): Unimplemented step: it 
should be ok
4) Checkin out the lil buggles (We have a second scenario): Unimplemented 
step: a scenario
5) Checkin out the lil buggles (We have a second scenario): Unimplemented 
step: it is run
6) Checkin out the lil buggles (We have a second scenario): Unimplemented 
step: it should be ok
7) Checkin out the lil buggles (We have a second scenario): Unimplemented 
step: it is run again
8) Checkin out the lil buggles (We have a second scenario): Unimplemented 
step: it should bork



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

Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 22:51

Message:
forgot to note:
rspec edge revision 2894
rspec_on_rails edge revision 2894
rails edge revision 8146


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

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

From noreply at rubyforge.org  Fri Nov 16 00:39:07 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 16 Nov 2007 00:39:07 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15608 ] Story problem if parenthesis
	used in Given, When, Then or And
Message-ID: <20071116053907.C619618585B3@rubyforge.org>

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

Category: rails plugin
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: sinclair  bain (sinclair)
>Assigned to: David Chelimsky (dchelimsky)
Summary: Story problem if parenthesis used in Given, When, Then or And

Initial Comment:
VERSION: rspec rails plugin current edge version
XP/Cygwin on XP

Hi,
I hit this when trying to use parenthesis in my stories ... (that'll teach me!).

If a scenario looks  like the following:

Story "User has story with parentheses", %{
  As a user
  I want parenthesis
  So that ... well I just do 
}, :type => RailsStory do

  Scenario "the Given has parentheses" do
    Given "parenthesis () in the given " do
    end

    When "anything" do
    end
   
    Then "The error occurred while evaluating nil.perform " do
    end
 
  end
end

This fails with the following:

The error occurred while evaluating nil.perform
  /cygdrive/c/development/sandbox/prototypes/proj/config/../vendor/plugins/rspec/lib/spec/story/world.rb: 60:in `store_and_call'
/cygdrive/c/development/sandbox/prototypes/proj/config/../vendor/plugins/rspec/lib/spec/story/world.rb: 92:in `Given'
stories/parenthesis_error_story.rb:10


Looks like the problem is in the Step#matches? method
since
    "abc (re) def".match /abc (re) def/
returns nil
however
    "abc (re) def".match /abc \(re\) def/
returns the match

The Step#assign_expression method when modifed as follows

        def assign_expression(name)
          expression = name.dup
          if String === expression
            while expression =~ /(\$\w*)/
              expression.gsub!($1, "(.*)")
            end
           
            expression.gsub! '(', '\('     # here
            expression.gsub! ')', '\)'     # here

          end
          @expression = Regexp.new ("^#{expression}$")
        end

Then the specs pass.

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

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

Message:
Fixed in 2900.

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

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

From noreply at rubyforge.org  Fri Nov 16 02:02:40 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 16 Nov 2007 02:02:40 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15670 ] Win32 + autotest --colour +
	script/rspec + win32console == NO OUTPUT
Message-ID: <20071116070240.6E05418585B2@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Will Green (hotgazpacho)
Assigned to: Nobody (None)
Summary: Win32 + autotest --colour + script/rspec + win32console == NO OUTPUT

Initial Comment:
* Windows Vista Home Premium, 32 bit
* Ruby 1.8.6 (2007-03-13 patchlevel 0) [i386-mswin32] (One-Click 186-25)
* Rails 1.2.5
* rspec plugin 1.0.8 (tags/CURRENT) (also have Gem RSpec, 1.0.8)
* rspc_on_rails plugin 1.0.8 (tags/CURRENT)
* Win32Console 1.0.8
* ZenTest 3.6.1

spec/spec.opts:
--colour
--format
progress
--loadby
mtime
--reverse

>From the root of my Rails app:

> autotest
loading autotest/rails_rspec
C:\ruby\bin\ruby.exe -S script/spec -O spec/spec.opts spec/models/membership_application_spec.rb

>>> no output

> spec -O spec/spec.opts spec/models/membership_application_spec.rb
............

Finished in 1.317 seconds

12 examples, 0 failures

>>> The line of dots and the "12 examples..." are both in green.

Something about script/spec is causing all output to be lost.

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

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

From noreply at rubyforge.org  Fri Nov 16 02:04:06 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 16 Nov 2007 02:04:06 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15670 ] Win32 + autotest --colour +
	script/rspec + win32console == NO OUTPUT
Message-ID: <20071116070406.BAF9C18585B1@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Will Green (hotgazpacho)
Assigned to: Nobody (None)
Summary: Win32 + autotest --colour + script/rspec + win32console == NO OUTPUT

Initial Comment:
* Windows Vista Home Premium, 32 bit
* Ruby 1.8.6 (2007-03-13 patchlevel 0) [i386-mswin32] (One-Click 186-25)
* Rails 1.2.5
* rspec plugin 1.0.8 (tags/CURRENT) (also have Gem RSpec, 1.0.8)
* rspc_on_rails plugin 1.0.8 (tags/CURRENT)
* Win32Console 1.0.8
* ZenTest 3.6.1

spec/spec.opts:
--colour
--format
progress
--loadby
mtime
--reverse

>From the root of my Rails app:

> autotest
loading autotest/rails_rspec
C:\ruby\bin\ruby.exe -S script/spec -O spec/spec.opts spec/models/membership_application_spec.rb

>>> no output

> spec -O spec/spec.opts spec/models/membership_application_spec.rb
............

Finished in 1.317 seconds

12 examples, 0 failures

>>> The line of dots and the "12 examples..." are both in green.

Something about script/spec is causing all output to be lost.

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

>Comment By: Will Green (hotgazpacho)
Date: 2007-11-16 02:04

Message:
If I remove --colour from spec/spec.opts, then  I get
output, but it is NOT colored.

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

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

From noreply at rubyforge.org  Fri Nov 16 02:12:04 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 16 Nov 2007 02:12:04 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15670 ] Win32 + autotest --colour +
	script/rspec + win32console == NO OUTPUT
Message-ID: <20071116071204.4EC3618585BE@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Will Green (hotgazpacho)
Assigned to: Nobody (None)
Summary: Win32 + autotest --colour + script/rspec + win32console == NO OUTPUT

Initial Comment:
* Windows Vista Home Premium, 32 bit
* Ruby 1.8.6 (2007-03-13 patchlevel 0) [i386-mswin32] (One-Click 186-25)
* Rails 1.2.5
* rspec plugin 1.0.8 (tags/CURRENT) (also have Gem RSpec, 1.0.8)
* rspc_on_rails plugin 1.0.8 (tags/CURRENT)
* Win32Console 1.0.8
* ZenTest 3.6.1

spec/spec.opts:
--colour
--format
progress
--loadby
mtime
--reverse

>From the root of my Rails app:

> autotest
loading autotest/rails_rspec
C:\ruby\bin\ruby.exe -S script/spec -O spec/spec.opts spec/models/membership_application_spec.rb

>>> no output

> spec -O spec/spec.opts spec/models/membership_application_spec.rb
............

Finished in 1.317 seconds

12 examples, 0 failures

>>> The line of dots and the "12 examples..." are both in green.

Something about script/spec is causing all output to be lost.

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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-16 07:12

Message:
Will - thanks for the report - but 1.0.8 is quite old by now :).

Since none of us on the dev team have vista, would you do us a favor and install the rspec's trunk and let us know if you still have this problem?

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

Comment By: Will Green (hotgazpacho)
Date: 2007-11-16 07:04

Message:
If I remove --colour from spec/spec.opts, then  I get
output, but it is NOT colored.

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

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

From noreply at rubyforge.org  Fri Nov 16 02:28:27 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 16 Nov 2007 02:28:27 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15670 ] Win32 + autotest --colour +
	script/rspec + win32console == NO OUTPUT
Message-ID: <20071116072827.7718D18585C0@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Will Green (hotgazpacho)
Assigned to: Nobody (None)
Summary: Win32 + autotest --colour + script/rspec + win32console == NO OUTPUT

Initial Comment:
* Windows Vista Home Premium, 32 bit
* Ruby 1.8.6 (2007-03-13 patchlevel 0) [i386-mswin32] (One-Click 186-25)
* Rails 1.2.5
* rspec plugin 1.0.8 (tags/CURRENT) (also have Gem RSpec, 1.0.8)
* rspc_on_rails plugin 1.0.8 (tags/CURRENT)
* Win32Console 1.0.8
* ZenTest 3.6.1

spec/spec.opts:
--colour
--format
progress
--loadby
mtime
--reverse

>From the root of my Rails app:

> autotest
loading autotest/rails_rspec
C:\ruby\bin\ruby.exe -S script/spec -O spec/spec.opts spec/models/membership_application_spec.rb

>>> no output

> spec -O spec/spec.opts spec/models/membership_application_spec.rb
............

Finished in 1.317 seconds

12 examples, 0 failures

>>> The line of dots and the "12 examples..." are both in green.

Something about script/spec is causing all output to be lost.

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

>Comment By: Will Green (hotgazpacho)
Date: 2007-11-16 02:28

Message:
Updated to trunk on both rspec and rspec_on_rails plugins.
Still no output with --colour in spec/spec.opts.

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

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

Message:
Will - thanks for the report - but 1.0.8 is quite old by now :).

Since none of us on the dev team have vista, would you do us a favor and install the rspec's trunk and let us know if you still have this problem?

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

Comment By: Will Green (hotgazpacho)
Date: 2007-11-16 02:04

Message:
If I remove --colour from spec/spec.opts, then  I get
output, but it is NOT colored.

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

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

From noreply at rubyforge.org  Fri Nov 16 09:23:49 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 16 Nov 2007 09:23:49 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-15675 ] [PATCH] fix helper specs
	statistics in rspec on rails 1.0.8
Message-ID: <20071116142349.84B5418585BD@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Chris Scharf (scharfie)
Assigned to: Nobody (None)
Summary: [PATCH] fix helper specs statistics in rspec on rails 1.0.8

Initial Comment:
Running rake stats reports incorrect values for helper specs -- a typo causes the helper specs to be the same as the view specs.  This patch fixes the typo.

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

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

From noreply at rubyforge.org  Fri Nov 16 09:25:44 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 16 Nov 2007 09:25:44 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-15676 ] [PATCH] Fixes [#13208]
	Specdoc outputs wrong spec names with drbserver
Message-ID: <20071116142544.9A33F18585F0@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Chris Scharf (scharfie)
Assigned to: Nobody (None)
Summary: [PATCH] Fixes [#13208] Specdoc outputs wrong spec names with drbserver

Initial Comment:
This patch fixes the issue of using drb and seeing "DrbServer" objects instead of the actual context.  (See #13208).

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

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

From noreply at rubyforge.org  Fri Nov 16 11:37:28 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 16 Nov 2007 11:37:28 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-15676 ] [PATCH] Fixes [#13208]
	Specdoc outputs wrong spec names with drbserver
Message-ID: <20071116163728.8AA3E18585E4@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Chris Scharf (scharfie)
Assigned to: Nobody (None)
Summary: [PATCH] Fixes [#13208] Specdoc outputs wrong spec names with drbserver

Initial Comment:
This patch fixes the issue of using drb and seeing "DrbServer" objects instead of the actual context.  (See #13208).

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-11-16 16:37

Message:
I doubt this one will be accepted without some specs (and running rake pre_commit).

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

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

From noreply at rubyforge.org  Sat Nov 17 16:30:46 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 17 Nov 2007 16:30:46 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-15709 ] [PATCH] Have SimpleMatchers
	expose their description for specdocs
Message-ID: <20071117213046.C5AD618585A0@rubyforge.org>

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

Category: expectation module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Bryan Helmkamp (brynary)
Assigned to: Nobody (None)
Summary: [PATCH] Have SimpleMatchers expose their description for specdocs

Initial Comment:
I'm loving the simplicity of writing custom matchers with SimpleMatcher. The convenience has led me to write very descriptive matchers like "validate_presence_of(attribute)". The result is that the strings I would be passing in to the #it method are identical to my matchers. For example:

it "should validate presence of name" do
  @story.should validate_presence_of(:name)
end

I prefer to shorten these to:

it { @story.should validate_presence_of(:name) }

The problem is that SimpleMatcher doesn't expose it's description instance variable to be used in specdocs.

This simple patch fixes that.

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

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

From psq at nanorails.com  Sun Nov 18 05:47:47 2007
From: psq at nanorails.com (Pascal)
Date: Sun, 18 Nov 2007 02:47:47 -0800
Subject: [rspec-devel] Edge rspec - running Test::Unit tests
Message-ID: <66036C9C-37C2-40F7-83FB-642B70CE4DDE@nanorails.com>

> Posted by David Chelimsky (Guest) on 14.10.2007 15:54
> On 10/12/07, Alvin Schur <a.schur at nucleus.com> wrote:
> >
> >     Finished in 4.5e-05 seconds
> >
> >     0 examples, 0 failures
> >
> >
> > How can I get Test::Unit and rspec to happily co-exist again?
>
> This is due to a refactoring that we're doing. We thought it was
> almost done so we moved it to trunk. We were wrong.
>
> This issue is on the radar and will be addressed before the next
> release.
I'd be happy to help on this.  Anyone can provide any thoughts on how  
you envision implementing it?

Cheers,
Pascal.
--
http://blog.nanorails.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20071118/d24f822f/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: email.png
Type: image/png
Size: 764 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/rspec-devel/attachments/20071118/d24f822f/attachment-0001.png 

From dchelimsky at gmail.com  Sun Nov 18 05:52:08 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sun, 18 Nov 2007 04:52:08 -0600
Subject: [rspec-devel] Edge rspec - running Test::Unit tests
In-Reply-To: <66036C9C-37C2-40F7-83FB-642B70CE4DDE@nanorails.com>
References: <66036C9C-37C2-40F7-83FB-642B70CE4DDE@nanorails.com>
Message-ID: <57c63afe0711180252y71bb35c6jd477757df6868a42@mail.gmail.com>

On Nov 18, 2007 4:47 AM, Pascal <psq at nanorails.com> wrote:
>
> Posted by David Chelimsky (Guest)
> on 14.10.2007 15:54
> On 10/12/07, Alvin Schur <a.schur at nucleus.com> wrote:
> >
> > Finished in 4.5e-05 seconds
> >
> > 0 examples, 0 failures
> >
> >
> > How can I get Test::Unit and rspec to happily co-exist again?
>
> This is due to a refactoring that we're doing. We thought it was
> almost done so we moved it to trunk. We were wrong.
>
> This issue is on the radar and will be addressed before the next
> release.
> I'd be happy to help on this.  Anyone can provide any thoughts on how you
> envision implementing it?

This particular problem has been addressed and we're pretty close to a
release at this point. We've (mostly Aslak) started to add stories for
T::U integration and this particular problem is already fixed. Feel
free to peek at the trunk and see how the stories are working and if
you have any ideas to add or enhance them.

Cheers,
David

>
> Cheers,
> Pascal.
> --
> http://blog.nanorails.com
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From dchelimsky at gmail.com  Sun Nov 18 10:05:52 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sun, 18 Nov 2007 09:05:52 -0600
Subject: [rspec-devel] Rails 2.0 RC1
In-Reply-To: <1f3be0490711142051sa097f7clfbd4533876c56d9@mail.gmail.com>
References: <1f3be0490711142051sa097f7clfbd4533876c56d9@mail.gmail.com>
Message-ID: <57c63afe0711180705n2e1cc358x978ddd7a192067d6@mail.gmail.com>

On Nov 14, 2007 10:51 PM, Tim Morgan <tmorgan99 at gmail.com> wrote:
> Hello.
> I found I had to make the following patches to account for differences
> in Rails 2.0.0 RC1:
>
> $  svn diff vendor/plugins/rspec_on_rails/
> Index: vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/helper.rb
> ===================================================================
> --- vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/helper.rb
>       (revision 2885)
> +++ vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/helper.rb
>       (working copy)
> @@ -27,8 +27,8 @@
>            include ActionView::Helpers::FormHelper
>            include ActionView::Helpers::FormOptionsHelper
>            include ActionView::Helpers::FormTagHelper
> -          include ActionView::Helpers::JavaScriptHelper
> -          include ActionView::Helpers::JavaScriptMacrosHelper
> +          include ActionView::Helpers::JavaScriptHelper rescue nil
> +          include ActionView::Helpers::JavaScriptMacrosHelper rescue nil
>            include ActionView::Helpers::NumberHelper
>            include ActionView::Helpers::PaginationHelper rescue nil
> #removed after 1.2.3
>            include ActionView::Helpers::PrototypeHelper
> Index: vendor/plugins/rspec_on_rails/lib/spec/rails.rb
> ===================================================================
> --- vendor/plugins/rspec_on_rails/lib/spec/rails.rb     (revision 2885)
> +++ vendor/plugins/rspec_on_rails/lib/spec/rails.rb     (working copy)
> @@ -17,7 +17,8 @@
>  require File.expand_path("#{dir}/rails/extensions")
>  require File.expand_path("#{dir}/rails/matchers")
>
> -Test::Unit.run = true
> +require 'test/test_helper'
> +  Test::Unit.run = true
>
>  module Spec
>    # = Spec::Rails
>
>
> ie. some ActionView::Helpers are no longer available?
> and test/test_helper is not loaded.
>
> Hope it helps!

Thanks - but that code is long gone from trunk. If you're using
2.0.0-RC1 you should probably be using trunk rev 2880 or later (best
to get that latest).

Cheers,
David

From noreply at rubyforge.org  Sun Nov 18 11:03:07 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 11:03:07 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-15675 ] [PATCH] fix helper specs
	statistics in rspec on rails 1.0.8
Message-ID: <20071118160308.08DD718585B2@rubyforge.org>

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

Category: None
Group: None
>Status: Closed
>Resolution: Out of Date
Priority: 3
Submitted By: Chris Scharf (scharfie)
Assigned to: Nobody (None)
Summary: [PATCH] fix helper specs statistics in rspec on rails 1.0.8

Initial Comment:
Running rake stats reports incorrect values for helper specs -- a typo causes the helper specs to be the same as the view specs.  This patch fixes the typo.

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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-18 16:03

Message:
This was already fixed in rspec's trunk and will part of the 1.1 release.

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

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

From noreply at rubyforge.org  Sun Nov 18 11:03:40 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 11:03:40 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-15676 ] [PATCH] Fixes [#13208]
	Specdoc outputs wrong spec names with drbserver
Message-ID: <20071118160340.59AAD18585A2@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Chris Scharf (scharfie)
Assigned to: Nobody (None)
Summary: [PATCH] Fixes [#13208] Specdoc outputs wrong spec names with drbserver

Initial Comment:
This patch fixes the issue of using drb and seeing "DrbServer" objects instead of the actual context.  (See #13208).

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-11-16 16:37

Message:
I doubt this one will be accepted without some specs (and running rake pre_commit).

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

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

From noreply at rubyforge.org  Sun Nov 18 11:10:32 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 11:10:32 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-15676 ] [PATCH] Fixes [#13208]
	Specdoc outputs wrong spec names with drbserver
Message-ID: <20071118161032.D3BEE18585A2@rubyforge.org>

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

Category: None
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 3
Submitted By: Chris Scharf (scharfie)
>Assigned to: David Chelimsky (dchelimsky)
Summary: [PATCH] Fixes [#13208] Specdoc outputs wrong spec names with drbserver

Initial Comment:
This patch fixes the issue of using drb and seeing "DrbServer" objects instead of the actual context.  (See #13208).

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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-18 16:10

Message:
This patch is against a pretty old version. I'm not even sure where it should go in trunk.

Scott is right. I'm going to close this. Feel free to reopen with a patch against trunk (at least a recent version of it) with specs that will fail if the change is not added.

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-11-16 16:37

Message:
I doubt this one will be accepted without some specs (and running rake pre_commit).

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

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

From noreply at rubyforge.org  Sun Nov 18 12:20:02 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 12:20:02 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-15718 ] warn user when two
	examples with the same name appear in the same example group
Message-ID: <20071118172002.32095185859A@rubyforge.org>

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

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Nobody (None)
Summary: warn user when two examples with the same name appear in the same example group

Initial Comment:
Right now if you do this:

describe Foo do
  it "should bar" do
    ...
  end

  it "should bar" do
    ...
  end
end

RSpec will run both examples and provide output like this:

Foo
- should bar
- should bar

Perhaps rspec should warn you or raise an error when you do this.


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

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

From noreply at rubyforge.org  Sun Nov 18 12:36:01 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 12:36:01 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15719 ] when a method is stubbed and
	then mocked, error message is misleading
Message-ID: <20071118173601.A9B9B185859A@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Nobody (None)
Summary: when a method is stubbed and then mocked, error message is misleading

Initial Comment:
module Spec
  module Mocks
    describe "mock failure when the mock receives the right message with the wrong args" do
      it "should tell you when it receives the right message with the wrong args" do
        m = mock("foo")
        m.should_receive(:bar).with("message")
        lambda {
          m.bar("different message")
        }.should raise_error(Spec::Mocks::MockExpectationError, %Q{Mock 'foo' expected :bar with ("message") but received it with ("different message")})
        m.bar("message") # allows the spec to pass
      end

      it "should tell you when it receives the right message with the wrong args if you stub the method" do
        pending("fix bug") do
          m = mock("foo")
          m.stub!(:bar)
          m.should_receive(:bar).with("message")
          lambda {
            m.bar("different message")
          }.should raise_error(Spec::Mocks::MockExpectationError, %Q{Mock 'foo' expected :bar with ("message") but received it with ("different message")})
          m.bar("message") # allows the spec to pass
        end
      end
    end
  end
end

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

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

From dchelimsky at gmail.com  Sun Nov 18 16:10:58 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sun, 18 Nov 2007 15:10:58 -0600
Subject: [rspec-devel] [ANN] Lighthouse and Engine Yard sponsorships
Message-ID: <57c63afe0711181310i7d6c08e2ib6f826221b837af8@mail.gmail.com>

Hey all,

I'm very happy to announce that ActiveReload[1] has generously offered
to sponsor a lighthouse[2] account for rspec. We'll be moving ticket
tracking there. We've already got the account set up and will soon
make it public.

We're also going to be getting a sponsored slice at Engine Yard[3] to
host source control, which will be either mercurial or git (TBD but
we're leaning towards mercurial). We'll continue to push source to svn
at rubyforge, so those of you who prefer to stay with svn can do so,
but those changes will likely be pushed once daily as opposed to every
commit.

It's going to take some time before we get these new systems up and
operational. We'll make additional announcements as we get closer to
actually making the moves.

Cheers,
David

[1] http://activereload.net
[2] http://lighthouseapp.com/
[3] http://engineyard.com

From dchelimsky at gmail.com  Sun Nov 18 16:16:41 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sun, 18 Nov 2007 15:16:41 -0600
Subject: [rspec-devel] help anyone?
Message-ID: <57c63afe0711181316l7875bcdcsda1927b9e61f6b0e@mail.gmail.com>

Hi everybody.

Per http://rubyforge.org/pipermail/rspec-users/2007-November/004572.html,
we're going to be moving ticket tracking over to lighthouse. We'd like
to get this rolling sooner than later, but we're fairly well occupied
getting ready for the 1.1 release and writing rspec books :)

We've got the lighthouse account set up. The thing we need to do to
start using it is to get all the open tickets at rubyforge copied over
to lighthouse. As of today, lighthouse does not offer any sort of
automated means of doing that.

If any of you are interested in helping out by either manually copying
tickets over or devising an automated means of doing so, please speak
up. It would be a big help to the both the rspec community and the
rspec development team.

Cheers,
David

From chad at spicycode.com  Sun Nov 18 16:25:14 2007
From: chad at spicycode.com (Chad Humphries)
Date: Sun, 18 Nov 2007 16:25:14 -0500
Subject: [rspec-devel] [ANN] Lighthouse and Engine Yard sponsorships
In-Reply-To: <57c63afe0711181310i7d6c08e2ib6f826221b837af8@mail.gmail.com>
References: <57c63afe0711181310i7d6c08e2ib6f826221b837af8@mail.gmail.com>
Message-ID: <4CC1660D-E65F-4C32-9532-AAD220F5C483@spicycode.com>

Great news on the hosting + lighthouse.  I'm all for git personally,  
but as long as there is an alt interface (ala svn) I doubt it will  
matter what format the core is in.

- Chad

On Nov 18, 2007, at 4:10 PM, David Chelimsky wrote:

> Hey all,
>
> I'm very happy to announce that ActiveReload[1] has generously offered
> to sponsor a lighthouse[2] account for rspec. We'll be moving ticket
> tracking there. We've already got the account set up and will soon
> make it public.
>
> We're also going to be getting a sponsored slice at Engine Yard[3] to
> host source control, which will be either mercurial or git (TBD but
> we're leaning towards mercurial). We'll continue to push source to svn
> at rubyforge, so those of you who prefer to stay with svn can do so,
> but those changes will likely be pushed once daily as opposed to every
> commit.
>
> It's going to take some time before we get these new systems up and
> operational. We'll make additional announcements as we get closer to
> actually making the moves.
>
> Cheers,
> David
>
> [1] http://activereload.net
> [2] http://lighthouseapp.com/
> [3] http://engineyard.com
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From chad at spicycode.com  Sun Nov 18 16:27:29 2007
From: chad at spicycode.com (Chad Humphries)
Date: Sun, 18 Nov 2007 16:27:29 -0500
Subject: [rspec-devel] help anyone?
In-Reply-To: <57c63afe0711181316l7875bcdcsda1927b9e61f6b0e@mail.gmail.com>
References: <57c63afe0711181316l7875bcdcsda1927b9e61f6b0e@mail.gmail.com>
Message-ID: <FFD12815-9A16-41AA-ABD0-16484535AB87@spicycode.com>

David,

I can either automate or manually move over tickets today -> pre  
thanksgiving.

-Chad

On Nov 18, 2007, at 4:16 PM, David Chelimsky wrote:

> Hi everybody.
>
> Per http://rubyforge.org/pipermail/rspec-users/2007-November/004572.html 
> ,
> we're going to be moving ticket tracking over to lighthouse. We'd like
> to get this rolling sooner than later, but we're fairly well occupied
> getting ready for the 1.1 release and writing rspec books :)
>
> We've got the lighthouse account set up. The thing we need to do to
> start using it is to get all the open tickets at rubyforge copied over
> to lighthouse. As of today, lighthouse does not offer any sort of
> automated means of doing that.
>
> If any of you are interested in helping out by either manually copying
> tickets over or devising an automated means of doing so, please speak
> up. It would be a big help to the both the rspec community and the
> rspec development team.
>
> Cheers,
> David
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From court3nay at gmail.com  Sun Nov 18 16:27:16 2007
From: court3nay at gmail.com (Courtenay)
Date: Sun, 18 Nov 2007 13:27:16 -0800
Subject: [rspec-devel] [ANN] Lighthouse and Engine Yard sponsorships
In-Reply-To: <57c63afe0711181310i7d6c08e2ib6f826221b837af8@mail.gmail.com>
References: <57c63afe0711181310i7d6c08e2ib6f826221b837af8@mail.gmail.com>
Message-ID: <57891DDF-5B41-48CF-A295-FC3422855650@gmail.com>





On Nov 18, 2007, at 1:10 PM, "David Chelimsky" <dchelimsky at gmail.com>  
wrote:

> Hey all,
>
> I'm very happy to announce that ActiveReload[1] has generously offered
> to sponsor a lighthouse[2] account for rspec. We'll be moving ticket
> tracking there. We've already got the account set up and will soon
> make it public.
>
> We're also going to be getting a sponsored slice at Engine Yard[3] to
> host source control, which will be either mercurial or git (TBD but
> we're leaning towards mercurial). We'll continue to push source to svn
> at rubyforge, so those of you who prefer to stay with svn can do so,
> but those changes will likely be pushed once daily as opposed to every
> commit.


Git +1
:)

>
>
> It's going to take some time before we get these new systems up and
> operational. We'll make additional announcements as we get closer to
> actually making the moves.
>
> Cheers,
> David
>
> [1] http://activereload.net
> [2] http://lighthouseapp.com/
> [3] http://engineyard.com
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel

From mailing_lists at railsnewbie.com  Sun Nov 18 16:38:02 2007
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Sun, 18 Nov 2007 16:38:02 -0500
Subject: [rspec-devel] help anyone?
In-Reply-To: <57c63afe0711181316l7875bcdcsda1927b9e61f6b0e@mail.gmail.com>
References: <57c63afe0711181316l7875bcdcsda1927b9e61f6b0e@mail.gmail.com>
Message-ID: <3C5EA177-6655-44B8-A166-D702E041F96D@railsnewbie.com>


On Nov 18, 2007, at 4:16 PM, David Chelimsky wrote:

> Hi everybody.
>
> Per http://rubyforge.org/pipermail/rspec-users/2007-November/ 
> 004572.html,
> we're going to be moving ticket tracking over to lighthouse. We'd like
> to get this rolling sooner than later, but we're fairly well occupied
> getting ready for the 1.1 release and writing rspec books :)
>
> We've got the lighthouse account set up. The thing we need to do to
> start using it is to get all the open tickets at rubyforge copied over
> to lighthouse. As of today, lighthouse does not offer any sort of
> automated means of doing that.
>
> If any of you are interested in helping out by either manually copying
> tickets over or devising an automated means of doing so, please speak
> up. It would be a big help to the both the rspec community and the
> rspec development team.

Yep, sign me up.  Lighthouse is pretty nice.

Scott


From dchelimsky at gmail.com  Sun Nov 18 16:38:06 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sun, 18 Nov 2007 15:38:06 -0600
Subject: [rspec-devel] help anyone?
In-Reply-To: <FFD12815-9A16-41AA-ABD0-16484535AB87@spicycode.com>
References: <57c63afe0711181316l7875bcdcsda1927b9e61f6b0e@mail.gmail.com>
	<FFD12815-9A16-41AA-ABD0-16484535AB87@spicycode.com>
Message-ID: <57c63afe0711181338v52778217l2b2f880b12f3361b@mail.gmail.com>

On Nov 18, 2007 3:27 PM, Chad Humphries <chad at spicycode.com> wrote:
> David,
>
> I can either automate or manually move over tickets today -> pre
> thanksgiving.

Chad - you're on! Thanks.

I've opened the project for public access:

http://rspec.lighthouseapp.com/

If anyone else is interested in helping, please coordinate with Chad
so we don't have a duplicate effort.

Cheers,
David

>
> -Chad
>
>
> On Nov 18, 2007, at 4:16 PM, David Chelimsky wrote:
>
> > Hi everybody.
> >
> > Per http://rubyforge.org/pipermail/rspec-users/2007-November/004572.html
> > ,
> > we're going to be moving ticket tracking over to lighthouse. We'd like
> > to get this rolling sooner than later, but we're fairly well occupied
> > getting ready for the 1.1 release and writing rspec books :)
> >
> > We've got the lighthouse account set up. The thing we need to do to
> > start using it is to get all the open tickets at rubyforge copied over
> > to lighthouse. As of today, lighthouse does not offer any sort of
> > automated means of doing that.
> >
> > If any of you are interested in helping out by either manually copying
> > tickets over or devising an automated means of doing so, please speak
> > up. It would be a big help to the both the rspec community and the
> > rspec development team.
> >
> > Cheers,
> > David
> > _______________________________________________
> > 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  Sun Nov 18 17:26:17 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sun, 18 Nov 2007 16:26:17 -0600
Subject: [rspec-devel] [rspec-users] help anyone?
In-Reply-To: <C33E9BF7-9B2C-4934-B7D6-C6708E1FFA61@parkerhill.com>
References: <57c63afe0711181316l7875bcdcsda1927b9e61f6b0e@mail.gmail.com>
	<C33E9BF7-9B2C-4934-B7D6-C6708E1FFA61@parkerhill.com>
Message-ID: <57c63afe0711181426m10730239g3b8c7f4c52c390e3@mail.gmail.com>

On Nov 18, 2007 4:16 PM, Jonathan Linowes <jonathan at parkerhill.com> wrote:
> David,
>
> If no one else offers a more efficient solution, I'm willing to
> manually copy the open tickets. (I count 37 of them)
> I have read access to Rubyforge
> and see this as an opportunity to get familiar with lighthouse

Thanks Jonathan, but Chad Humpries has already offered to do this (on
the rspec-devel list).

Also - there are 37 but there are also 9 patches and 77 feature
requests. We need them all to get moved over.

If you want to coordinate w/ Chad and Scott (who also volunteered),
perhaps you guys can divide and conquer.

Cheers,
David

>
> Jonathan
>
>
> On Nov 18, 2007, at 4:16 PM, David Chelimsky wrote:
>
>
> > Hi everybody.
> >
> > Per http://rubyforge.org/pipermail/rspec-users/2007-November/
> > 004572.html,
> > we're going to be moving ticket tracking over to lighthouse. We'd like
> > to get this rolling sooner than later, but we're fairly well occupied
> > getting ready for the 1.1 release and writing rspec books :)
> >
> > We've got the lighthouse account set up. The thing we need to do to
> > start using it is to get all the open tickets at rubyforge copied over
> > to lighthouse. As of today, lighthouse does not offer any sort of
> > automated means of doing that.
> >
> > If any of you are interested in helping out by either manually copying
> > tickets over or devising an automated means of doing so, please speak
> > up. It would be a big help to the both the rspec community and the
> > rspec development team.
> >
> > Cheers,
> > David
> > _______________________________________________
> > rspec-users mailing list
> > rspec-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-users
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

From dchelimsky at gmail.com  Sun Nov 18 17:34:30 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sun, 18 Nov 2007 16:34:30 -0600
Subject: [rspec-devel] help anyone?
In-Reply-To: <57c63afe0711181316l7875bcdcsda1927b9e61f6b0e@mail.gmail.com>
References: <57c63afe0711181316l7875bcdcsda1927b9e61f6b0e@mail.gmail.com>
Message-ID: <57c63afe0711181434o7d948049p490d32378c38147a@mail.gmail.com>

On Nov 18, 2007 3:16 PM, David Chelimsky <dchelimsky at gmail.com> wrote:
> Hi everybody.
>
> Per http://rubyforge.org/pipermail/rspec-users/2007-November/004572.html,
> we're going to be moving ticket tracking over to lighthouse. We'd like
> to get this rolling sooner than later, but we're fairly well occupied
> getting ready for the 1.1 release and writing rspec books :)
>
> We've got the lighthouse account set up. The thing we need to do to
> start using it is to get all the open tickets at rubyforge copied over
> to lighthouse. As of today, lighthouse does not offer any sort of
> automated means of doing that.
>
> If any of you are interested in helping out by either manually copying
> tickets over or devising an automated means of doing so, please speak
> up. It would be a big help to the both the rspec community and the
> rspec development team.

A few people have offered on the two different lists (rspec-users and
rspec-devel), so it looks like this might happen sooner than later.

Some ground rules:

We need to get all of the open tickets at rubyforge in all three
trackers: bugs, patches and feature requests. Right now there are 123
in total.

There is only one tracker at lighthouse, and tickets are grouped via
tags. So tickets that come from the bug tracker should be tagged
'bug'. From Feature Requests: 'featurerequest'. From Patches: 'patch'.
Simple?

The LH ticket should either include all of the commentary from the RF
ticket or at least a link back to the old ticket for reference.

Do not worry about assigning responsibility. We will grab tickets that
we want to work on.

When they get moved over, they should get closed on rubyforge with a
message saying "This ticket was moved to" with a link to the new
ticket.

I'll put up a notice on Rubyforge that we are moving to lighthouse and
new tickets should go there with a cutoff (i.e. any ticket above 15719
on rubyforge will be ignored). I don't know yet if I can archive those
trackers. I'll look into that this week.

Questions?

Cheers,
David

>
> Cheers,
> David
>

From pergesu at gmail.com  Sun Nov 18 17:53:01 2007
From: pergesu at gmail.com (Pat Maddox)
Date: Sun, 18 Nov 2007 14:53:01 -0800
Subject: [rspec-devel] [ANN] Lighthouse and Engine Yard sponsorships
In-Reply-To: <57891DDF-5B41-48CF-A295-FC3422855650@gmail.com>
References: <57c63afe0711181310i7d6c08e2ib6f826221b837af8@mail.gmail.com>
	<57891DDF-5B41-48CF-A295-FC3422855650@gmail.com>
Message-ID: <810a540e0711181453i788003d3xfa74580535426e1d@mail.gmail.com>

On Nov 18, 2007 1:27 PM, Courtenay <court3nay at gmail.com> wrote:
>
>
>
>
> On Nov 18, 2007, at 1:10 PM, "David Chelimsky" <dchelimsky at gmail.com>
> wrote:
>
> > Hey all,
> >
> > I'm very happy to announce that ActiveReload[1] has generously offered
> > to sponsor a lighthouse[2] account for rspec. We'll be moving ticket
> > tracking there. We've already got the account set up and will soon
> > make it public.
> >
> > We're also going to be getting a sponsored slice at Engine Yard[3] to
> > host source control, which will be either mercurial or git (TBD but
> > we're leaning towards mercurial). We'll continue to push source to svn
> > at rubyforge, so those of you who prefer to stay with svn can do so,
> > but those changes will likely be pushed once daily as opposed to every
> > commit.
>
>
> Git +1
> :)

+2 :)

From psq at nanorails.com  Sun Nov 18 18:31:32 2007
From: psq at nanorails.com (Pascal)
Date: Sun, 18 Nov 2007 15:31:32 -0800
Subject: [rspec-devel] Edge rspec - running Test::Unit tests
In-Reply-To: <57c63afe0711180252y71bb35c6jd477757df6868a42@mail.gmail.com>
References: <66036C9C-37C2-40F7-83FB-642B70CE4DDE@nanorails.com>
	<57c63afe0711180252y71bb35c6jd477757df6868a42@mail.gmail.com>
Message-ID: <CAA622E5-DA6F-4E29-B895-4C1236E27680@nanorails.com>


On Nov 18, 2007, at 2:52 AM, David Chelimsky wrote:

> On Nov 18, 2007 4:47 AM, Pascal <psq at nanorails.com> wrote:
>>
>> Posted by David Chelimsky (Guest)
>> on 14.10.2007 15:54
>> On 10/12/07, Alvin Schur <a.schur at nucleus.com> wrote:
>>>
>>> Finished in 4.5e-05 seconds
>>>
>>> 0 examples, 0 failures
>>>
>>>
>>> How can I get Test::Unit and rspec to happily co-exist again?
>>
>> This is due to a refactoring that we're doing. We thought it was
>> almost done so we moved it to trunk. We were wrong.
>>
>> This issue is on the radar and will be addressed before the next
>> release.
>> I'd be happy to help on this.  Anyone can provide any thoughts on  
>> how you
>> envision implementing it?
>
> This particular problem has been addressed and we're pretty close to a
> release at this point. We've (mostly Aslak) started to add stories for
> T::U integration and this particular problem is already fixed. Feel
> free to peek at the trunk and see how the stories are working and if
> you have any ideas to add or enhance them.

Thanks!

I'm still experiencing some issues running trunk (2910) wit rails 2.0  
(8166), it works when I run an individual test (it runs tests and  
specs, and report on each one), but not when running rake test:units.   
It runs the specs and reports on them, then I get a "rake aborted".   
I'll investigate later today what the failure is (no useful message  
displayed).  The problem could be on my side.

What's the class running the test cases?  Somewhere in the Runner?

Cheers,
Pascal.
--
http://blog.nanorails.com

>
>
> Cheers,
> David
>
>>
>> Cheers,
>> Pascal.
>> --
>> http://blog.nanorails.com
>> _______________________________________________
>> 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 nathan.sutton at gmail.com  Sun Nov 18 18:30:15 2007
From: nathan.sutton at gmail.com (Nathan Sutton)
Date: Sun, 18 Nov 2007 17:30:15 -0600
Subject: [rspec-devel] [ANN] Lighthouse and Engine Yard sponsorships
In-Reply-To: <57c63afe0711181310i7d6c08e2ib6f826221b837af8@mail.gmail.com>
References: <57c63afe0711181310i7d6c08e2ib6f826221b837af8@mail.gmail.com>
Message-ID: <831E250B-F14A-416F-9403-98D7A619F8D7@gmail.com>

Git +1

Nathan Sutton
fowlduck at gmail.com
rspec edge revision 2894
rspec_on_rails edge revision 2894
rails edge revision 8146




On Nov 18, 2007, at 3:10 PM, David Chelimsky wrote:

> Hey all,
>
> I'm very happy to announce that ActiveReload[1] has generously offered
> to sponsor a lighthouse[2] account for rspec. We'll be moving ticket
> tracking there. We've already got the account set up and will soon
> make it public.
>
> We're also going to be getting a sponsored slice at Engine Yard[3] to
> host source control, which will be either mercurial or git (TBD but
> we're leaning towards mercurial). We'll continue to push source to svn
> at rubyforge, so those of you who prefer to stay with svn can do so,
> but those changes will likely be pushed once daily as opposed to every
> commit.
>
> It's going to take some time before we get these new systems up and
> operational. We'll make additional announcements as we get closer to
> actually making the moves.
>
> Cheers,
> David
>
> [1] http://activereload.net
> [2] http://lighthouseapp.com/
> [3] http://engineyard.com
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From dchelimsky at gmail.com  Sun Nov 18 18:37:17 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sun, 18 Nov 2007 17:37:17 -0600
Subject: [rspec-devel] Edge rspec - running Test::Unit tests
In-Reply-To: <CAA622E5-DA6F-4E29-B895-4C1236E27680@nanorails.com>
References: <66036C9C-37C2-40F7-83FB-642B70CE4DDE@nanorails.com>
	<57c63afe0711180252y71bb35c6jd477757df6868a42@mail.gmail.com>
	<CAA622E5-DA6F-4E29-B895-4C1236E27680@nanorails.com>
Message-ID: <57c63afe0711181537n5684b7c3jbcf9f1b8ee4765ce@mail.gmail.com>

On Nov 18, 2007 5:31 PM, Pascal <psq at nanorails.com> wrote:
>
> On Nov 18, 2007, at 2:52 AM, David Chelimsky wrote:
>
> > On Nov 18, 2007 4:47 AM, Pascal <psq at nanorails.com> wrote:
> >>
> >> Posted by David Chelimsky (Guest)
> >> on 14.10.2007 15:54
> >> On 10/12/07, Alvin Schur <a.schur at nucleus.com> wrote:
> >>>
> >>> Finished in 4.5e-05 seconds
> >>>
> >>> 0 examples, 0 failures
> >>>
> >>>
> >>> How can I get Test::Unit and rspec to happily co-exist again?
> >>
> >> This is due to a refactoring that we're doing. We thought it was
> >> almost done so we moved it to trunk. We were wrong.
> >>
> >> This issue is on the radar and will be addressed before the next
> >> release.
> >> I'd be happy to help on this.  Anyone can provide any thoughts on
> >> how you
> >> envision implementing it?
> >
> > This particular problem has been addressed and we're pretty close to a
> > release at this point. We've (mostly Aslak) started to add stories for
> > T::U integration and this particular problem is already fixed. Feel
> > free to peek at the trunk and see how the stories are working and if
> > you have any ideas to add or enhance them.
>
> Thanks!
>
> I'm still experiencing some issues running trunk (2910) wit rails 2.0
> (8166), it works when I run an individual test (it runs tests and
> specs, and report on each one), but not when running rake test:units.

rake test:units is not supported by rspec

You want to use this instead:

rake spec:models

> It runs the specs and reports on them, then I get a "rake aborted".
> I'll investigate later today what the failure is (no useful message
> displayed).  The problem could be on my side.
>
> What's the class running the test cases?  Somewhere in the Runner?
>
>
> Cheers,
> Pascal.
> --
> http://blog.nanorails.com
>
> >
> >
> > Cheers,
> > David
> >
> >>
> >> Cheers,
> >> Pascal.
> >> --
> >> http://blog.nanorails.com
> >> _______________________________________________
> >> 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 ed.howland at gmail.com  Sun Nov 18 19:08:32 2007
From: ed.howland at gmail.com (Ed Howland)
Date: Sun, 18 Nov 2007 18:08:32 -0600
Subject: [rspec-devel] [ANN] Lighthouse and Engine Yard sponsorships
In-Reply-To: <831E250B-F14A-416F-9403-98D7A619F8D7@gmail.com>
References: <57c63afe0711181310i7d6c08e2ib6f826221b837af8@mail.gmail.com>
	<831E250B-F14A-416F-9403-98D7A619F8D7@gmail.com>
Message-ID: <3df642dd0711181608q71c3f66exaf88fd178af3b842@mail.gmail.com>

On Nov 18, 2007 5:30 PM, Nathan Sutton <nathan.sutton at gmail.com> wrote:
> Git +1

Git +1

Thanks
Ed


-
Ed Howland

From noreply at rubyforge.org  Sun Nov 18 19:53:10 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 19:53:10 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-13777 ] run last example action in
	textmate bundle
Message-ID: <20071119005310.5F7D9185859C@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: Chad Humphries (spicycode)
Date: 2007-11-18 19:53

Message:
This ticket was moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/8-run-last-example-action-in-textmate-bundle#ticket-8-2

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

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  Sun Nov 18 19:55:45 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 19:55:45 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-13907 ] Would like "exist" to be in
	Spec::Matchers (like the others)
Message-ID: <20071119005545.E60FD185859A@rubyforge.org>

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

Category: expectation module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Bret Pettichord  (bret)
Assigned to: Nobody (None)
Summary: Would like "exist" to be in Spec::Matchers (like the others)

Initial Comment:
I had submitted a patch http://rubyforge.org/tracker/?func=detail&group_id=797&aid=10473&atid=3152, but it was refactored in a way that reduced its scope. Specifically, I would like "should exist" to work in any class that includes Spec::Matchers, not just the it-blocks.

Attached please find an additional test that fails with the current version of Rspec (as well as prior versions), but passes with my originally submitted implementation of "exist". For convenience, i have included that implementation  in this test, so that the test actually passes if you apply the patch. To reproduced the failure, you'll have to remove this added class.

The right solution is probably more complicated, but i never quite understood how my original solution was refactored, so i'm not sure what the best solution would be.

Thank you for your consideration. With Watir, we regularly extract test code out of the specs, and therefore this ability is valuable to us. We have not seen this problem with the other methods in Spec::Matchers.

Bret

Index: C:/work/rspec-rspec/spec/spec/matchers/exist_spec.rb
===================================================================
--- C:/work/rspec-rspec/spec/spec/matchers/exist_spec.rb	(revision 2561)
+++ C:/work/rspec-rspec/spec/spec/matchers/exist_spec.rb	(working copy)
@@ -45,4 +45,47 @@
       should fail
   end
 end
+
+# Additional Test
+module Spec
+  module Matchers
+    class Exist
+      def matches? actual
+        @actual = actual
+        @actual.exist?
+      end
+      def failure_message
+        "expected #{@actual.inspect} to exist, but it doesn't."
+      end
+      def negative_failure_message
+        "expected #{@actual.inspect} to not exist, but it does."
+      end
+    end
+    def exist; Exist.new; end
+  end
+end
+
+class SubstanceTester
+  include Spec::Matchers
+  def initialize substance
+    @substance = substance
+  end
+  def assert_exists
+    @substance.should exist
+  end
+end
+
+describe "should exist, outside of a behavior" do
+  before(:each) do
+    @real = Substance.new true, 'something real'
+    @imaginary = Substance.new false, 'something imaginary'
+  end
+  it "should still pass if target exists" do
+    real_tester = SubstanceTester.new @real
+    real_tester.assert_exists
+  end
+end
+
+
+
     


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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 19:55

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/9-would-like-exist-to-be-in-spec-matchers-like-the-others

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-09-16 04:05

Message:
I added the failing example to r2566 (set to pending). We got rid of the matcher when we added a default set of predicate matchers that included exist. We only added that to the ExampleApi, so we'd need to move the whole predicate matchers bit over to Spec::Matchers to get it to work. This is now on the radar but not first priority. If you can figure out how to do that, feel free to submit another patch. Otherwise, we'll get to it eventually.

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

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

From noreply at rubyforge.org  Sun Nov 18 20:00:47 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 20:00:47 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-14082 ] [PATCH] allow stubs to yield
	and return values
Message-ID: <20071119010047.6C59A185859C@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: Chad Humphries (spicycode)
Date: 2007-11-18 20:00

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/10-allow-stubs-to-yield-and-return-values#ticket-10-2

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

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  Sun Nov 18 20:06:05 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 20:06:05 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-14109 ] RailsStory dies badly when no
	fixtures present
Message-ID: <20071119010605.263D8185845C@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: James Hughes (jpath)
Assigned to: Nobody (None)
Summary: RailsStory dies badly when no fixtures present

Initial Comment:
A story like the following: 

Story 'Something happens', %{
 As a user
 I want to do something
 So that something will happen.
}, :type => RailsStory do

 Scenario 'User doing something for first time' do
   Given 'a user' do
     @user = User.new
   end
   When 'the user makes a request' do
     post '/some_action', :id => 1
   end
   Then 'something should happen' do
   end
 end
end

will die attempting to post when there are no fixtures present (at least, I think that's what's happening.) It dies at the following line in rails/actionpack/lib/action_controller/integration.rb:

      self.class.fixture_table_names.each do |table_name|

'self.class' at this point is RailsStory. The attached patch just initializes fixture_table_names to an empty array.

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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 20:06

Message:
http://rspec.lighthouseapp.com/projects/5645/tickets/11-14109-railsstory-dies-badly-when-no-fixtures-present

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

Comment By: James Hughes (jpath)
Date: 2007-09-24 12:01

Message:
Ok, I've played with this a bit more, and the error seems to
just be with edge rails. Latest rails gem fails too, but
with a different error. My original patch has no effect on
this error, so, probably just a 'works for me' solution.

First, steps to reproduce:

Create a brand new rails app and freeze to edge
Do 'script/generate rspec_model user'
Put the story as it appears here in the stories folder (See
attached file)
Run 'ruby stories/test_story.rb'

This should produce the following stack trace:

FAILURES:
  1) Something happens (User doing something for first time)
FAILED
  NoMethodError: You have a nil object when you didn't
expect it!
You might have expected an instance of Array.
The error occurred while evaluating nil.each
 
/home/jhughes/dev/rspec_story_regression/vendor/rails/actionpack/lib/action_controller/integration.rb:522:in
`open_session'
/home/jhughes/dev/rspec_story_regression/vendor/rails/actionpack/lib/action_controller/integration.rb:493:in
`reset!'
/home/jhughes/dev/rspec_story_regression/vendor/rails/actionpack/lib/action_controller/integration.rb:498:in
`post'
stories/test_story.rb:17:in `the user makes a request'
/home/jhughes/dev/rspec_story_regression/vendor/plugins/rspec/lib/spec/story/simple_step.rb:13:in
`__send__'
/home/jhughes/dev/rspec_story_regression/vendor/plugins/rspec/lib/spec/story/simple_step.rb:13:in
`perform'
/home/jhughes/dev/rspec_story_regression/vendor/plugins/rspec/lib/spec/story/world.rb:58:in
`store_and_call'
/home/jhughes/dev/rspec_story_regression/vendor/plugins/rspec/lib/spec/story/world.rb:73:in
`When'
stories/test_story.rb:16
/home/jhughes/dev/rspec_story_regression/vendor/plugins/rspec/lib/spec/story/runner/scenario_runner.rb:14:in
`instance_eval'
/home/jhughes/dev/rspec_story_regression/vendor/plugins/rspec/lib/spec/story/runner/scenario_runner.rb:14:in
`run'
/home/jhughes/dev/rspec_story_regression/vendor/plugins/rspec/lib/spec/story/runner/story_runner.rb:48:in
`run_stories'
/home/jhughes/dev/rspec_story_regression/vendor/plugins/rspec/lib/spec/story/runner/story_runner.rb:43:in
`each'
/home/jhughes/dev/rspec_story_regression/vendor/plugins/rspec/lib/spec/story/runner/story_runner.rb:43:in
`run_stories'
/home/jhughes/dev/rspec_story_regression/vendor/plugins/rspec/lib/spec/story/runner/story_runner.rb:39:in
`each'
/home/jhughes/dev/rspec_story_regression/vendor/plugins/rspec/lib/spec/story/runner/story_runner.rb:39:in
`run_stories'
/home/jhughes/dev/rspec_story_regression/vendor/plugins/rspec/lib/spec/story/runner.rb:38:in
`register_exit_hook'
stories/test_story.rb:6

With the latest rails gem instead of edge, I get (note,
again, this happens whether my patch is applied or not:

/usr/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/initializer.rb:328:in
`send': undefined method `session=' for
ActionController::Base:Class (NoMethodError)
        from
/usr/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/initializer.rb:328:in
`initialize_framework_settings'
        from
/usr/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/initializer.rb:327:in
`each'
        from
/usr/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/initializer.rb:327:in
`initialize_framework_settings'
        from
/usr/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/initializer.rb:324:in
`each'
        from
/usr/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/initializer.rb:324:in
`initialize_framework_settings'
        from
/usr/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/initializer.rb:96:in
`process'
        from
/usr/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/initializer.rb:43:in
`send'
        from
/usr/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/initializer.rb:43:in
`run'
        from
/home/jhughes/dev/rspec_story_regression/config/environment.rb:13
        from stories/test_story.rb:2:in `require'
        from stories/test_story.rb:2


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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-09-22 23:56

Message:
Please post a real example with a real stack trace. I haven't seen this problem and would like to understand it better before adding anything like this.

Cheers,
David

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

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

From noreply at rubyforge.org  Sun Nov 18 20:06:42 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 20:06:42 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-13777 ] run last example action in
	textmate bundle
Message-ID: <20071119010642.7235E1858595@rubyforge.org>

Patches item #13777, was opened at 2007-09-08 18: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: Closed
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: David Chelimsky (dchelimsky)
Date: 2007-11-19 01:06

Message:
Closing this as it has been moved to lighthouse.

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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 00:53

Message:
This ticket was moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/8-run-last-example-action-in-textmate-bundle#ticket-8-2

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-11-05 23: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 21:51

Message:
I added it a while back,

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-09-08 21: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  Sun Nov 18 20:07:25 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 20:07:25 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-13907 ] Would like "exist" to be in
	Spec::Matchers (like the others)
Message-ID: <20071119010725.225A2185859A@rubyforge.org>

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

Category: expectation module
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Bret Pettichord  (bret)
Assigned to: Nobody (None)
>Summary: Would like "exist" to be in Spec::Matchers (like the others)

Initial Comment:
I had submitted a patch http://rubyforge.org/tracker/?func=detail&group_id=797&aid=10473&atid=3152, but it was refactored in a way that reduced its scope. Specifically, I would like "should exist" to work in any class that includes Spec::Matchers, not just the it-blocks.

Attached please find an additional test that fails with the current version of Rspec (as well as prior versions), but passes with my originally submitted implementation of "exist". For convenience, i have included that implementation  in this test, so that the test actually passes if you apply the patch. To reproduced the failure, you'll have to remove this added class.

The right solution is probably more complicated, but i never quite understood how my original solution was refactored, so i'm not sure what the best solution would be.

Thank you for your consideration. With Watir, we regularly extract test code out of the specs, and therefore this ability is valuable to us. We have not seen this problem with the other methods in Spec::Matchers.

Bret

Index: C:/work/rspec-rspec/spec/spec/matchers/exist_spec.rb
===================================================================
--- C:/work/rspec-rspec/spec/spec/matchers/exist_spec.rb	(revision 2561)
+++ C:/work/rspec-rspec/spec/spec/matchers/exist_spec.rb	(working copy)
@@ -45,4 +45,47 @@
       should fail
   end
 end
+
+# Additional Test
+module Spec
+  module Matchers
+    class Exist
+      def matches? actual
+        @actual = actual
+        @actual.exist?
+      end
+      def failure_message
+        "expected #{@actual.inspect} to exist, but it doesn't."
+      end
+      def negative_failure_message
+        "expected #{@actual.inspect} to not exist, but it does."
+      end
+    end
+    def exist; Exist.new; end
+  end
+end
+
+class SubstanceTester
+  include Spec::Matchers
+  def initialize substance
+    @substance = substance
+  end
+  def assert_exists
+    @substance.should exist
+  end
+end
+
+describe "should exist, outside of a behavior" do
+  before(:each) do
+    @real = Substance.new true, 'something real'
+    @imaginary = Substance.new false, 'something imaginary'
+  end
+  it "should still pass if target exists" do
+    real_tester = SubstanceTester.new @real
+    real_tester.assert_exists
+  end
+end
+
+
+
     


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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 00:55

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/9-would-like-exist-to-be-in-spec-matchers-like-the-others

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-09-16 08:05

Message:
I added the failing example to r2566 (set to pending). We got rid of the matcher when we added a default set of predicate matchers that included exist. We only added that to the ExampleApi, so we'd need to move the whole predicate matchers bit over to Spec::Matchers to get it to work. This is now on the radar but not first priority. If you can figure out how to do that, feel free to submit another patch. Otherwise, we'll get to it eventually.

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

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

From noreply at rubyforge.org  Sun Nov 18 20:08:03 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 20:08:03 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-14140 ] fix for TM when switching to
	alternate file
Message-ID: <20071119010804.0220C1858598@rubyforge.org>

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

Category: RSpec.tmbundle
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Trevor Squires (protocool)
Assigned to: David Chelimsky (dchelimsky)
Summary: fix for TM when switching to alternate file

Initial Comment:
When using textmate's ctrl-shift-downarrow (switch to "Alternate File") command I get exceptions of "undefined method + for NilClass".

Note: this *only* happens if the 'alternate file' you are trying to switch to does not exist, and you elect to let TM create it for you.

The problem appears to be down to content_for() incorrectly checking the file_type parameter.  It looks for 'spec' even though it would seem 'model spec' and 'view spec' are examples of the values it receives.

I've attached a patch which corrects this issue for me.

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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 20:08

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/12-14140-fix-for-tm-when-switching-to-alternate-file#ticket-12-3

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-02 18:48

Message:
Please add a spec that fails without this change and passes with it. There are specs in RSpec.tmbundle/Support. You can run them thusly:

cd RSpec.tmbundle/Support
rake spec

They were failing recently due to a bug that I just fixed, so please make sure you've got the most recent trunk.

Thanks.

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

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

From noreply at rubyforge.org  Sun Nov 18 20:08:40 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 20:08:40 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-14082 ] [PATCH] allow stubs to yield
	and return values
Message-ID: <20071119010840.F1B1E1858598@rubyforge.org>

Patches item #14082, was opened at 2007-09-19 21: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: Closed
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: Chad Humphries (spicycode)
Date: 2007-11-19 01:00

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/10-allow-stubs-to-yield-and-return-values#ticket-10-2

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-11-05 23: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  Sun Nov 18 20:09:35 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 20:09:35 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-14109 ] RailsStory dies badly when no
	fixtures present
Message-ID: <20071119010935.F07101858598@rubyforge.org>

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

Category: rails plugin
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: James Hughes (jpath)
Assigned to: Nobody (None)
Summary: RailsStory dies badly when no fixtures present

Initial Comment:
A story like the following: 

Story 'Something happens', %{
 As a user
 I want to do something
 So that something will happen.
}, :type => RailsStory do

 Scenario 'User doing something for first time' do
   Given 'a user' do
     @user = User.new
   end
   When 'the user makes a request' do
     post '/some_action', :id => 1
   end
   Then 'something should happen' do
   end
 end
end

will die attempting to post when there are no fixtures present (at least, I think that's what's happening.) It dies at the following line in rails/actionpack/lib/action_controller/integration.rb:

      self.class.fixture_table_names.each do |table_name|

'self.class' at this point is RailsStory. The attached patch just initializes fixture_table_names to an empty array.

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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 01:06

Message:
http://rspec.lighthouseapp.com/projects/5645/tickets/11-14109-railsstory-dies-badly-when-no-fixtures-present

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

Comment By: James Hughes (jpath)
Date: 2007-09-24 16:01

Message:
Ok, I've played with this a bit more, and the error seems to
just be with edge rails. Latest rails gem fails too, but
with a different error. My original patch has no effect on
this error, so, probably just a 'works for me' solution.

First, steps to reproduce:

Create a brand new rails app and freeze to edge
Do 'script/generate rspec_model user'
Put the story as it appears here in the stories folder (See
attached file)
Run 'ruby stories/test_story.rb'

This should produce the following stack trace:

FAILURES:
  1) Something happens (User doing something for first time)
FAILED
  NoMethodError: You have a nil object when you didn't
expect it!
You might have expected an instance of Array.
The error occurred while evaluating nil.each
 
/home/jhughes/dev/rspec_story_regression/vendor/rails/actionpack/lib/action_controller/integration.rb:522:in
`open_session'
/home/jhughes/dev/rspec_story_regression/vendor/rails/actionpack/lib/action_controller/integration.rb:493:in
`reset!'
/home/jhughes/dev/rspec_story_regression/vendor/rails/actionpack/lib/action_controller/integration.rb:498:in
`post'
stories/test_story.rb:17:in `the user makes a request'
/home/jhughes/dev/rspec_story_regression/vendor/plugins/rspec/lib/spec/story/simple_step.rb:13:in
`__send__'
/home/jhughes/dev/rspec_story_regression/vendor/plugins/rspec/lib/spec/story/simple_step.rb:13:in
`perform'
/home/jhughes/dev/rspec_story_regression/vendor/plugins/rspec/lib/spec/story/world.rb:58:in
`store_and_call'
/home/jhughes/dev/rspec_story_regression/vendor/plugins/rspec/lib/spec/story/world.rb:73:in
`When'
stories/test_story.rb:16
/home/jhughes/dev/rspec_story_regression/vendor/plugins/rspec/lib/spec/story/runner/scenario_runner.rb:14:in
`instance_eval'
/home/jhughes/dev/rspec_story_regression/vendor/plugins/rspec/lib/spec/story/runner/scenario_runner.rb:14:in
`run'
/home/jhughes/dev/rspec_story_regression/vendor/plugins/rspec/lib/spec/story/runner/story_runner.rb:48:in
`run_stories'
/home/jhughes/dev/rspec_story_regression/vendor/plugins/rspec/lib/spec/story/runner/story_runner.rb:43:in
`each'
/home/jhughes/dev/rspec_story_regression/vendor/plugins/rspec/lib/spec/story/runner/story_runner.rb:43:in
`run_stories'
/home/jhughes/dev/rspec_story_regression/vendor/plugins/rspec/lib/spec/story/runner/story_runner.rb:39:in
`each'
/home/jhughes/dev/rspec_story_regression/vendor/plugins/rspec/lib/spec/story/runner/story_runner.rb:39:in
`run_stories'
/home/jhughes/dev/rspec_story_regression/vendor/plugins/rspec/lib/spec/story/runner.rb:38:in
`register_exit_hook'
stories/test_story.rb:6

With the latest rails gem instead of edge, I get (note,
again, this happens whether my patch is applied or not:

/usr/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/initializer.rb:328:in
`send': undefined method `session=' for
ActionController::Base:Class (NoMethodError)
        from
/usr/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/initializer.rb:328:in
`initialize_framework_settings'
        from
/usr/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/initializer.rb:327:in
`each'
        from
/usr/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/initializer.rb:327:in
`initialize_framework_settings'
        from
/usr/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/initializer.rb:324:in
`each'
        from
/usr/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/initializer.rb:324:in
`initialize_framework_settings'
        from
/usr/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/initializer.rb:96:in
`process'
        from
/usr/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/initializer.rb:43:in
`send'
        from
/usr/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/initializer.rb:43:in
`run'
        from
/home/jhughes/dev/rspec_story_regression/config/environment.rb:13
        from stories/test_story.rb:2:in `require'
        from stories/test_story.rb:2


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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-09-23 03:56

Message:
Please post a real example with a real stack trace. I haven't seen this problem and would like to understand it better before adding anything like this.

Cheers,
David

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

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

From noreply at rubyforge.org  Sun Nov 18 20:10:03 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 20:10:03 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-14140 ] fix for TM when switching to
	alternate file
Message-ID: <20071119011004.4BAA61858598@rubyforge.org>

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

Category: RSpec.tmbundle
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Trevor Squires (protocool)
Assigned to: David Chelimsky (dchelimsky)
Summary: fix for TM when switching to alternate file

Initial Comment:
When using textmate's ctrl-shift-downarrow (switch to "Alternate File") command I get exceptions of "undefined method + for NilClass".

Note: this *only* happens if the 'alternate file' you are trying to switch to does not exist, and you elect to let TM create it for you.

The problem appears to be down to content_for() incorrectly checking the file_type parameter.  It looks for 'spec' even though it would seem 'model spec' and 'view spec' are examples of the values it receives.

I've attached a patch which corrects this issue for me.

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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 01:08

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/12-14140-fix-for-tm-when-switching-to-alternate-file#ticket-12-3

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-02 22:48

Message:
Please add a spec that fails without this change and passes with it. There are specs in RSpec.tmbundle/Support. You can run them thusly:

cd RSpec.tmbundle/Support
rake spec

They were failing recently due to a bug that I just fixed, so please make sure you've got the most recent trunk.

Thanks.

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

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

From noreply at rubyforge.org  Sun Nov 18 20:11:00 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 20:11:00 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-15461 ] RaiseError should give at
	least the first line of backtrace when it encounters an
	unexpected exception
Message-ID: <20071119011100.AA92E1858598@rubyforge.org>

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

Category: expectation module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Alan Shields (sshields)
Assigned to: Nobody (None)
Summary: RaiseError should give at least the first line of backtrace when it encounters an unexpected exception

Initial Comment:
which is more useful:

NoMethodError in 'blah... should allow the user object to be passed in'
undefined method `null?' for #<User:0x34cf81c>
/Users/sshields/code/appsw/config/../vendor/plugins/dollars_and_cents/lib/dollars_and_cents.rb:48:in `method_missing'
./spec/models/blah_spec.rb:46:
script/spec:4:

ooooor

'blah... should allow the user object to be passed in' FAILED
expected no Exception, got #<NoMethodError: You have a nil object when you didn't expect it!
The error occurred while evaluating nil.to_time> from /Users/sshields/code/appsw/config/../app/models/calculation.rb:329:in `compute_range_rollup'
./spec/models/calculation_spec.rb:49:
script/spec:4:

Work paid for by 6bar8.com - makers of sweetspot.dm

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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 20:11

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/13-15461-raiseerror-should-give-at-least-the-first-line-of-backtrace-when-it-encounters-an-unexpected-exception

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

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

From noreply at rubyforge.org  Sun Nov 18 20:11:48 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 20:11:48 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-15461 ] RaiseError should give at
	least the first line of backtrace when it encounters an
	unexpected exception
Message-ID: <20071119011148.5DA711858598@rubyforge.org>

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

Category: expectation module
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Alan Shields (sshields)
Assigned to: Nobody (None)
Summary: RaiseError should give at least the first line of backtrace when it encounters an unexpected exception

Initial Comment:
which is more useful:

NoMethodError in 'blah... should allow the user object to be passed in'
undefined method `null?' for #<User:0x34cf81c>
/Users/sshields/code/appsw/config/../vendor/plugins/dollars_and_cents/lib/dollars_and_cents.rb:48:in `method_missing'
./spec/models/blah_spec.rb:46:
script/spec:4:

ooooor

'blah... should allow the user object to be passed in' FAILED
expected no Exception, got #<NoMethodError: You have a nil object when you didn't expect it!
The error occurred while evaluating nil.to_time> from /Users/sshields/code/appsw/config/../app/models/calculation.rb:329:in `compute_range_rollup'
./spec/models/calculation_spec.rb:49:
script/spec:4:

Work paid for by 6bar8.com - makers of sweetspot.dm

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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 01:11

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/13-15461-raiseerror-should-give-at-least-the-first-line-of-backtrace-when-it-encounters-an-unexpected-exception

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

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

From noreply at rubyforge.org  Sun Nov 18 20:12:15 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 20:12:15 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-15565 ] [PATCH] Adding support for
	by_at_least/by_at_most in Change matcher.
Message-ID: <20071119011215.3B49F1858598@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Saimon Moore (saimon)
Assigned to: Nobody (None)
Summary: [PATCH] Adding support for by_at_least/by_at_most in Change matcher. 

Initial Comment:
Added the following methods to Spec::Matchers:Change

def by_at_least(minimum);...end 

def by_at_most(maximum);...end

Example specs:

  it "should pass when attribute is changed by greater than the expected amount" do
    lambda { @instance.some_value += 2 }.should change(@instance, :some_value).by_at_least(1)
  end

  it "should pass when attribute is changed by less than the expected amount" do
    lambda { @instance.some_value += 2 }.should change(@instance, :some_value).by_at_most(3)
  end

Patch has full specs and updated documentation.


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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 20:12

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/14-15565-patch-adding-support-for-by_at_least-by_at_most-in-change-matcher

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

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

From noreply at rubyforge.org  Sun Nov 18 20:12:53 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 20:12:53 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-15565 ] [PATCH] Adding support for
	by_at_least/by_at_most in Change matcher.
Message-ID: <20071119011253.8D73E185859A@rubyforge.org>

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

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Saimon Moore (saimon)
Assigned to: Nobody (None)
Summary: [PATCH] Adding support for by_at_least/by_at_most in Change matcher. 

Initial Comment:
Added the following methods to Spec::Matchers:Change

def by_at_least(minimum);...end 

def by_at_most(maximum);...end

Example specs:

  it "should pass when attribute is changed by greater than the expected amount" do
    lambda { @instance.some_value += 2 }.should change(@instance, :some_value).by_at_least(1)
  end

  it "should pass when attribute is changed by less than the expected amount" do
    lambda { @instance.some_value += 2 }.should change(@instance, :some_value).by_at_most(3)
  end

Patch has full specs and updated documentation.


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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 01:12

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/14-15565-patch-adding-support-for-by_at_least-by_at_most-in-change-matcher

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

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

From noreply at rubyforge.org  Sun Nov 18 20:13:28 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 20:13:28 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-15597 ] [PATCH] Reverse loading of
	ActionView::Base helper modules
Message-ID: <20071119011328.3DF72185859A@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Mark Van Holstyn (lotswholetime)
Assigned to: Nobody (None)
Summary: [PATCH] Reverse loading of ActionView::Base helper modules

Initial Comment:
I have one application which aliases some view helpers. The code works fine, but the specs fail with this error...

~/application/vendor/rails/activesupport/lib/active_support/core_ext/module/aliasing.rb:31:in `alias_method': undefined method `expand_javascript_sources' for class `Spec::Rails::DSL::HelperExample' (NameError)
    from ~/application/vendor/rails/activesupport/lib/active_support/core_ext/module/aliasing.rb:31:in `alias_method_chain'
    from ~/application/vendor/plugins/dhtml_calendar/lib/helpers/calendar.rb:59:in `included'
    from ~/application/vendor/plugins/dhtml_calendar/lib/helpers/calendar.rb:58:in `class_eval'
    from ~/application/vendor/plugins/dhtml_calendar/lib/helpers/calendar.rb:58:in `included'
    from ~/application/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/helper_example.rb:37:in `include'
    from ~/application/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/helper_example.rb:37
    from ~/application/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/helper_example.rb:36:in `each'
    from ~/application/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/helper_example.rb:36
     ... 51 levels...
    from ~/application/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:13:in `load_files'
    from ~/application/vendor/plugins/rspec/lib/spec/runner/options.rb:73:in `run_examples'
    from ~/application/vendor/plugins/rspec/lib/spec/runner/command_line.rb:19:in `run'
    from ~/application/vendor/plugins/rspec/bin/spec:3

Looking at the code, I notice this:

ActionView::Base.included_modules.each do |mod|
  include mod if mod.parents.include?(ActionView::Helpers)
end

The problem is that "included_modules" returns the included modules in the reverse order that they were included.

>> ActionView::Base.included_modules
=> [#<Module:0x192cca4>, ActionController::Routing::Helpers, ActionController::PolymorphicRoutes, WillPaginate::ViewHelpers, FileColumnHelper, ActionView::Helpers::DhtmlCalendarHelper, ActionView::Helpers::UrlHelper, ActionView::Helpers::TextHelper, ActionView::Helpers::TagHelper, ActionView::Helpers::ScriptaculousHelper, ActionView::Helpers::SanitizeHelper, ActionView::Helpers::RecordTagHelper, ActionView::Helpers::RecordIdentificationHelper, ActionView::Helpers::NumberHelper, ActionView::Helpers::JavaScriptHelper, ActionView::Helpers::PrototypeHelper, ActionView::Helpers::FormTagHelper, ActionView::Helpers::FormOptionsHelper, ActionView::Helpers::FormHelper, ActionView::Helpers::DebugHelper, ActionView::Helpers::DateHelper, ActionView::Helpers::CaptureHelper, ActionView::Helpers::CacheHelper, ActionView::Helpers::BenchmarkHelper, ActionView::Helpers::AtomFeedHelper, ActionView::Helpers::AssetTagHelper, ActionView::Helpers::ActiveRecordHelper, ActionView::Partials, ActionView::Base::CompiledTemplates, ERB::Util, InstanceExecMethods, Base64::Deprecated, Base64, PP::ObjectMixin, Kernel]

My module is now included BEFORE any of the modules provided by rails, so the alias call fails. This patch changes the HelperExample definition to  reverse the array returned from included_modules so that they are included in the proper order.


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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 20:13

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/15-15597-reverse-loading-of-actionview-base-helper-modules

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

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

From noreply at rubyforge.org  Sun Nov 18 20:15:10 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 20:15:10 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-15709 ] [PATCH] Have SimpleMatchers
	expose their description for specdocs
Message-ID: <20071119011510.4ABE91858598@rubyforge.org>

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

Category: expectation module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Bryan Helmkamp (brynary)
Assigned to: Nobody (None)
Summary: [PATCH] Have SimpleMatchers expose their description for specdocs

Initial Comment:
I'm loving the simplicity of writing custom matchers with SimpleMatcher. The convenience has led me to write very descriptive matchers like "validate_presence_of(attribute)". The result is that the strings I would be passing in to the #it method are identical to my matchers. For example:

it "should validate presence of name" do
  @story.should validate_presence_of(:name)
end

I prefer to shorten these to:

it { @story.should validate_presence_of(:name) }

The problem is that SimpleMatcher doesn't expose it's description instance variable to be used in specdocs.

This simple patch fixes that.

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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 20:15

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/16-15709-have-simplematchers-expose-their-description-for-specdocs

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

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

From noreply at rubyforge.org  Sun Nov 18 20:20:33 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 20:20:33 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-4836 ] Generate sequence
	diagrams from specs using plotutils/pic2plot and UMLGraph's
	sequence.pic script
Message-ID: <20071119012033.CD02F1858598@rubyforge.org>

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

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Aslak Helles?y (aslak_hellesoy)
Assigned to: Nobody (None)
Summary: Generate sequence diagrams from specs using plotutils/pic2plot and UMLGraph's sequence.pic script

Initial Comment:
A spec using mocks contains all the information to generate a sequence diagram.

For an example see examples/file_accessor_spec.rb

The idea is that if we run specs with --sequence, RSpec could output a text file for each spec, representing the sequence diagram. We could use the format described at 
http://www.spinellis.gr/sw/umlgraph/

Then we could just run pic2plot over the generated file (using UMLGraph's BSD-licenced sequence.pic script) to generate sequence diagrams as png, gif or ps.



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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 20:20

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/17-4836-generate-sequence-diagrams-from-specs-using-plotutils-pic2plot-and-umlgraph-s-sequence-pic-script#ticket-17-2

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2006-06-22 11:21

Message:
A more comrehensive guide of the sequence diagram syntax is at the second half of http://www.spinellis.gr/sw/umlgraph/doc/indexw.html

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

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

From noreply at rubyforge.org  Sun Nov 18 20:22:06 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 20:22:06 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-5064 ] Let mock() take a
	class argument
Message-ID: <20071119012206.9702C185859A@rubyforge.org>

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

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Aslak Helles?y (aslak_hellesoy)
Assigned to: Nobody (None)
Summary: Let mock() take a class argument

Initial Comment:
I'd like to start my development by using:
  thing = mock("thing")

Once I have discovered thing's interface, I'd like to switch to:
  thing = mock(Thing)

The idea is that should_expect would fail as long as Thing doesn't implement the expected method.
This is a great way to go to the next step - implementing the Thing interface.



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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 20:22

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/18-5064-let-mock-take-a-class-argument#ticket-18-2

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

Comment By: Pat Maddox (pergesu)
Date: 2006-11-29 23:13

Message:
ooh!  I just had a decent (I think) idea.

Instead of passing in a class, we can check to see if a class implement's the interface we've discovered on a particular mock.  For example

... specs

specify "Thing should implement foo, bar, baz" do
  Thing.should_implement(@mock_thing)
end

should_implement would be really simple.  Just loop through all the mocked/stubbed methods on @mock_thing and see if Thing responds to each one.

If Thing doesn't conform to the interface, the output is something like
'Thing should implement foo, bar, baz' FAILED
Thing doesn't implement
  - foo
  - baz

Since Ruby is dynamically typed, we lose a little bit (in some cases, perhaps such as this) where we don't have a defined interface.  But I think it's dangerous to let the spec code get coupled to concrete collaborator classes.  We can take advantage of Ruby here by verifying that a class satisfies the same interface as a mock we're using.

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

Comment By: Pat Maddox (pergesu)
Date: 2006-11-29 23:06

Message:
As I mentioned earlier, the problem with this is that the specs will now be coupled to a concrete class.  That is a bad direction for us to take RSpec, considering that it's (imo) the best tool for driving development.

What about instead of passing in a class, we just have a command line switch that shows each mock's interface?  rspec --show-interfaces thing_spec.rb produces:
Thing
 - foo
 - bar
 - baz

I know that's not quite what you want, but it will easily let you see if your class conforms to the interface.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2006-11-29 19:15

Message:
There are a lot of different ideas expressed in this thread. The thing that would be the most simple and, in my view, the most useful, would be Aslak's initial request BUT instead of failing you'd get feedback. We wouldn't use this for integration at all. So, if you do this:

thing = mock('thing')

you get things as they are now. If you do this:

thing = mock(Thing)

you get things as they are now, w/ failure messages reading 'Thing'. Then, if you CHOOSE to, you can run the spec command w/ a switch that simply provides a report of methods that are being called on the mock Thing that Thing will not respond to.

This can be very helpful when doing a top-down style of development in which mocks are used to help you discover the interfaces of the collaborators. In a statically typed language like java, you get this benefit automatically because you have to add methods to a java interface as you discover them. This facility in rspec would give you that little extra edge.

The whole doubling as integration idea is probably silly.

Cheers,
David

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

Comment By: Pat Maddox (pergesu)
Date: 2006-11-29 18:27

Message:
I've been thinking about this a lot over the past couple days.  We use rspec and mocks to specify the behavior of and interaction between objects.  When we mock behavior, all we care about is the interface - concrete classes shouldn't matter at all.

The more I think about it the less I like it.  Things like integration mode test behavior of the system, rather than of the objects themselves, and I think that's something that should be separate from the standard specifications.  Whether that's something that should be a part of RSpec, I'm not sure...but I am certain that testing the system behavior should be separate from specifying object behavior and interactions.

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

Comment By: Nathan Sobo (nathansobo)
Date: 2006-11-29 17:22

Message:
It would be helpful to continue to allow the mock method to take an optional descriptive string argument after the class argument.

Also, the should_receive method could be extended with an optional modifier that would suppress warnings for messages not corresponding to methods in the mocked class, such as messages that are known to be handled by method_missing. It could look like...

@mock.should_receive(:foo).and_not_warn
@mock.should_receive(:foo).not_in_interface

or something.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2006-10-12 07:25

Message:
I've been thinking about this a bit and I'd like to take it even further. The thing that bugs me about this idea is that I have to keep track of which mocks are using a name and which are using the Class.

What if we started creating an empty Thing class and wrote this:

thing = mock(Thing)

That would run if the class exists, but it not yet be defined in any detail.

Then we could run specs in varying modes. Normally, they would run as they do now, with the exception that the mock expectation would read "Mock <Thing> expected...." or something like that.

A second mode, invoked w/ a command line option, would be that it does the checking that you talk about to make sure that all the messages being mocked have corresponding methods on the real class.

A third mode would be something someone proposed on the email list - an integration mode. This would require some additional setup and I'm not sure what that looks like (perhaps an integration_setup block?), but the idea is that you could run all of the same specs using real objects instead of the mocks. You wouldn't have to write separate integration specs.

This is something Dan described about JBehave when he and I spoke at Agile 06. When you run JBehave, it tells you how many mocks are still being used. The idea there is that you should remove them over time - just use them to get you there, but use the real objects as they come to be. When there are no mocks in the run and all the specs pass, you're done!

The nice thing about having a CL option to run them this way is that you can monitor your progress towards "done", but you can also run the specs in isolation normally. This gives you the benefits of both worlds - isolation and integration. In fact the mock modes could be isolation (default), verification and integration. That has some nice symmetry to it.

Thoughts?

David

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

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

From noreply at rubyforge.org  Sun Nov 18 20:23:32 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 20:23:32 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-5544 ] should_output
	(includes complete method definition)
Message-ID: <20071119012332.C1BA4185859A@rubyforge.org>

Feature Requests item #5544, was opened at 2006-08-27 20:24
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5544&group_id=797

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Eero Saynatkari (esaynatkari)
Assigned to: Nobody (None)
Summary: should_output (includes complete method definition)

Initial Comment:
This expectation provides a way to specify program output.
It takes into account Readline which refuses to allow use
of StringIO or Tempfile. It is a bit ugly having to work
around symbolic names but seems to work fine in my code.


# Usage examples:

 lambda {UI.mainloop {|ui| ui.output 'foo'}}.should_output "foo\n"
 lambda {UI.mainloop {|ui| ui.output 'foo'}}.should_output /foo\n/

 lambda {UI.mainloop {|ui| ui.error 'foo'}}.should_output "foo\n", :to => '$stderr'

# Code:

# Modify RSpec a little
module Spec
  class ShouldHelper

    # Verify output from block is expected
    def output(expected, io = {:to => '$stdout'})
      to = io[:to]

      # Store the old stream
      eval "old_to = #{to}"

      # Replace, work around Readline
      eval %{
        #{to} = if $LOADED_FEATURES.grep(/readline/i).empty?
                  StringIO.new ''
                else
                  File.open '/tmp/rspec_output_#{$$}', 'w+'
                end                   # if readline
      }                               # eval
       
      @target.call 
      eval(to).rewind
      output = eval(to).read 

      # Match up
      case expected
        when Regexp
          output.should_match expected
        else 
          output.should_equal expected
      end                             # case expected
      
    # Clean up
    ensure
      eval %{
        #{to}, old_to = old_to, #{to}
        
        if old_to and old_to.kind_of? File
          require 'fileutils'
          old_to.close 
          FileUtils.rm_rf old_to.path
        end                           # if old_to
      }                               # eval
      false
    end                               # output()
  end                                 # ShouldHelper
end                                   # Spec


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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 20:23

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/19-5544-should_output-includes-complete-method-definition#ticket-19-2

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

Comment By: David Chelimsky (dchelimsky)
Date: 2006-10-26 11:58

Message:
Eero - I like this idea a lot. Would you consider submitting this as a patch against the trunk (pls indicate the revision number against which you are patching) including specs written in rspec.

Thanks,
David

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2006-08-29 08:04

Message:
Looks good, but where is the test case for this?


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

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

From noreply at rubyforge.org  Sun Nov 18 20:25:59 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 20:25:59 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-15597 ] [PATCH] Reverse loading of
	ActionView::Base helper modules
Message-ID: <20071119012559.A1BDD185859A@rubyforge.org>

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

Category: rails plugin
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Mark Van Holstyn (lotswholetime)
Assigned to: Nobody (None)
Summary: [PATCH] Reverse loading of ActionView::Base helper modules

Initial Comment:
I have one application which aliases some view helpers. The code works fine, but the specs fail with this error...

~/application/vendor/rails/activesupport/lib/active_support/core_ext/module/aliasing.rb:31:in `alias_method': undefined method `expand_javascript_sources' for class `Spec::Rails::DSL::HelperExample' (NameError)
    from ~/application/vendor/rails/activesupport/lib/active_support/core_ext/module/aliasing.rb:31:in `alias_method_chain'
    from ~/application/vendor/plugins/dhtml_calendar/lib/helpers/calendar.rb:59:in `included'
    from ~/application/vendor/plugins/dhtml_calendar/lib/helpers/calendar.rb:58:in `class_eval'
    from ~/application/vendor/plugins/dhtml_calendar/lib/helpers/calendar.rb:58:in `included'
    from ~/application/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/helper_example.rb:37:in `include'
    from ~/application/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/helper_example.rb:37
    from ~/application/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/helper_example.rb:36:in `each'
    from ~/application/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/helper_example.rb:36
     ... 51 levels...
    from ~/application/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:13:in `load_files'
    from ~/application/vendor/plugins/rspec/lib/spec/runner/options.rb:73:in `run_examples'
    from ~/application/vendor/plugins/rspec/lib/spec/runner/command_line.rb:19:in `run'
    from ~/application/vendor/plugins/rspec/bin/spec:3

Looking at the code, I notice this:

ActionView::Base.included_modules.each do |mod|
  include mod if mod.parents.include?(ActionView::Helpers)
end

The problem is that "included_modules" returns the included modules in the reverse order that they were included.

>> ActionView::Base.included_modules
=> [#<Module:0x192cca4>, ActionController::Routing::Helpers, ActionController::PolymorphicRoutes, WillPaginate::ViewHelpers, FileColumnHelper, ActionView::Helpers::DhtmlCalendarHelper, ActionView::Helpers::UrlHelper, ActionView::Helpers::TextHelper, ActionView::Helpers::TagHelper, ActionView::Helpers::ScriptaculousHelper, ActionView::Helpers::SanitizeHelper, ActionView::Helpers::RecordTagHelper, ActionView::Helpers::RecordIdentificationHelper, ActionView::Helpers::NumberHelper, ActionView::Helpers::JavaScriptHelper, ActionView::Helpers::PrototypeHelper, ActionView::Helpers::FormTagHelper, ActionView::Helpers::FormOptionsHelper, ActionView::Helpers::FormHelper, ActionView::Helpers::DebugHelper, ActionView::Helpers::DateHelper, ActionView::Helpers::CaptureHelper, ActionView::Helpers::CacheHelper, ActionView::Helpers::BenchmarkHelper, ActionView::Helpers::AtomFeedHelper, ActionView::Helpers::AssetTagHelper, ActionView::Helpers::ActiveRecordHelper, ActionView::Partials, ActionView::Base::CompiledTemplates, ERB::Util, InstanceExecMethods, Base64::Deprecated, Base64, PP::ObjectMixin, Kernel]

My module is now included BEFORE any of the modules provided by rails, so the alias call fails. This patch changes the HelperExample definition to  reverse the array returned from included_modules so that they are included in the proper order.


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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 01:13

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/15-15597-reverse-loading-of-actionview-base-helper-modules

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

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

From noreply at rubyforge.org  Sun Nov 18 20:26:03 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 20:26:03 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-5800 ] Make QuickRef.pdf
	part of the website
Message-ID: <20071119012603.9E11718585C9@rubyforge.org>

Feature Requests item #5800, was opened at 2006-09-18 17:48
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5800&group_id=797

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Aslak Helles?y (aslak_hellesoy)
Assigned to: Nobody (None)
Summary: Make QuickRef.pdf part of the website

Initial Comment:
The pdf must be moved to doc/src, a link must be created somewhere and we must make sure it's copied over to doc/output as part of the build

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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 20:26

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/20-5800-make-quickref-pdf-part-of-the-website#ticket-20-2

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-04-17 11:49

Message:
Yeah - the synatax on that pdf is really outdated.  If you don't have the source just delete it and close the ticket.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-04-16 21:09

Message:
Actually, I think we should remove it since we don't have the source so we can update it.

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

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

From noreply at rubyforge.org  Sun Nov 18 20:26:19 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 20:26:19 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-15709 ] [PATCH] Have SimpleMatchers
	expose their description for specdocs
Message-ID: <20071119012619.92A991858598@rubyforge.org>

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

Category: expectation module
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Bryan Helmkamp (brynary)
Assigned to: Nobody (None)
Summary: [PATCH] Have SimpleMatchers expose their description for specdocs

Initial Comment:
I'm loving the simplicity of writing custom matchers with SimpleMatcher. The convenience has led me to write very descriptive matchers like "validate_presence_of(attribute)". The result is that the strings I would be passing in to the #it method are identical to my matchers. For example:

it "should validate presence of name" do
  @story.should validate_presence_of(:name)
end

I prefer to shorten these to:

it { @story.should validate_presence_of(:name) }

The problem is that SimpleMatcher doesn't expose it's description instance variable to be used in specdocs.

This simple patch fixes that.

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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 01:15

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/16-15709-have-simplematchers-expose-their-description-for-specdocs

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

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

From noreply at rubyforge.org  Sun Nov 18 20:27:51 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 20:27:51 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-4836 ] Generate sequence
	diagrams from specs using plotutils/pic2plot and UMLGraph's
	sequence.pic script
Message-ID: <20071119012751.844161858598@rubyforge.org>

Feature Requests item #4836, was opened at 2006-06-22 15:15
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=4836&group_id=797

Category: None
Group: None
>Status: Closed
Priority: 3
Submitted By: Aslak Helles?y (aslak_hellesoy)
Assigned to: Nobody (None)
Summary: Generate sequence diagrams from specs using plotutils/pic2plot and UMLGraph's sequence.pic script

Initial Comment:
A spec using mocks contains all the information to generate a sequence diagram.

For an example see examples/file_accessor_spec.rb

The idea is that if we run specs with --sequence, RSpec could output a text file for each spec, representing the sequence diagram. We could use the format described at 
http://www.spinellis.gr/sw/umlgraph/

Then we could just run pic2plot over the generated file (using UMLGraph's BSD-licenced sequence.pic script) to generate sequence diagrams as png, gif or ps.



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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 01:20

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/17-4836-generate-sequence-diagrams-from-specs-using-plotutils-pic2plot-and-umlgraph-s-sequence-pic-script#ticket-17-2

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2006-06-22 15:21

Message:
A more comrehensive guide of the sequence diagram syntax is at the second half of http://www.spinellis.gr/sw/umlgraph/doc/indexw.html

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

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

From noreply at rubyforge.org  Sun Nov 18 20:28:11 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 20:28:11 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-5064 ] Let mock() take a
	class argument
Message-ID: <20071119012811.39D191858598@rubyforge.org>

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

Category: None
Group: None
>Status: Closed
Priority: 3
Submitted By: Aslak Helles?y (aslak_hellesoy)
Assigned to: Nobody (None)
Summary: Let mock() take a class argument

Initial Comment:
I'd like to start my development by using:
  thing = mock("thing")

Once I have discovered thing's interface, I'd like to switch to:
  thing = mock(Thing)

The idea is that should_expect would fail as long as Thing doesn't implement the expected method.
This is a great way to go to the next step - implementing the Thing interface.



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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 01:22

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/18-5064-let-mock-take-a-class-argument#ticket-18-2

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

Comment By: Pat Maddox (pergesu)
Date: 2006-11-30 04:13

Message:
ooh!  I just had a decent (I think) idea.

Instead of passing in a class, we can check to see if a class implement's the interface we've discovered on a particular mock.  For example

... specs

specify "Thing should implement foo, bar, baz" do
  Thing.should_implement(@mock_thing)
end

should_implement would be really simple.  Just loop through all the mocked/stubbed methods on @mock_thing and see if Thing responds to each one.

If Thing doesn't conform to the interface, the output is something like
'Thing should implement foo, bar, baz' FAILED
Thing doesn't implement
  - foo
  - baz

Since Ruby is dynamically typed, we lose a little bit (in some cases, perhaps such as this) where we don't have a defined interface.  But I think it's dangerous to let the spec code get coupled to concrete collaborator classes.  We can take advantage of Ruby here by verifying that a class satisfies the same interface as a mock we're using.

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

Comment By: Pat Maddox (pergesu)
Date: 2006-11-30 04:06

Message:
As I mentioned earlier, the problem with this is that the specs will now be coupled to a concrete class.  That is a bad direction for us to take RSpec, considering that it's (imo) the best tool for driving development.

What about instead of passing in a class, we just have a command line switch that shows each mock's interface?  rspec --show-interfaces thing_spec.rb produces:
Thing
 - foo
 - bar
 - baz

I know that's not quite what you want, but it will easily let you see if your class conforms to the interface.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2006-11-30 00:15

Message:
There are a lot of different ideas expressed in this thread. The thing that would be the most simple and, in my view, the most useful, would be Aslak's initial request BUT instead of failing you'd get feedback. We wouldn't use this for integration at all. So, if you do this:

thing = mock('thing')

you get things as they are now. If you do this:

thing = mock(Thing)

you get things as they are now, w/ failure messages reading 'Thing'. Then, if you CHOOSE to, you can run the spec command w/ a switch that simply provides a report of methods that are being called on the mock Thing that Thing will not respond to.

This can be very helpful when doing a top-down style of development in which mocks are used to help you discover the interfaces of the collaborators. In a statically typed language like java, you get this benefit automatically because you have to add methods to a java interface as you discover them. This facility in rspec would give you that little extra edge.

The whole doubling as integration idea is probably silly.

Cheers,
David

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

Comment By: Pat Maddox (pergesu)
Date: 2006-11-29 23:27

Message:
I've been thinking about this a lot over the past couple days.  We use rspec and mocks to specify the behavior of and interaction between objects.  When we mock behavior, all we care about is the interface - concrete classes shouldn't matter at all.

The more I think about it the less I like it.  Things like integration mode test behavior of the system, rather than of the objects themselves, and I think that's something that should be separate from the standard specifications.  Whether that's something that should be a part of RSpec, I'm not sure...but I am certain that testing the system behavior should be separate from specifying object behavior and interactions.

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

Comment By: Nathan Sobo (nathansobo)
Date: 2006-11-29 22:22

Message:
It would be helpful to continue to allow the mock method to take an optional descriptive string argument after the class argument.

Also, the should_receive method could be extended with an optional modifier that would suppress warnings for messages not corresponding to methods in the mocked class, such as messages that are known to be handled by method_missing. It could look like...

@mock.should_receive(:foo).and_not_warn
@mock.should_receive(:foo).not_in_interface

or something.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2006-10-12 11:25

Message:
I've been thinking about this a bit and I'd like to take it even further. The thing that bugs me about this idea is that I have to keep track of which mocks are using a name and which are using the Class.

What if we started creating an empty Thing class and wrote this:

thing = mock(Thing)

That would run if the class exists, but it not yet be defined in any detail.

Then we could run specs in varying modes. Normally, they would run as they do now, with the exception that the mock expectation would read "Mock <Thing> expected...." or something like that.

A second mode, invoked w/ a command line option, would be that it does the checking that you talk about to make sure that all the messages being mocked have corresponding methods on the real class.

A third mode would be something someone proposed on the email list - an integration mode. This would require some additional setup and I'm not sure what that looks like (perhaps an integration_setup block?), but the idea is that you could run all of the same specs using real objects instead of the mocks. You wouldn't have to write separate integration specs.

This is something Dan described about JBehave when he and I spoke at Agile 06. When you run JBehave, it tells you how many mocks are still being used. The idea there is that you should remove them over time - just use them to get you there, but use the real objects as they come to be. When there are no mocks in the run and all the specs pass, you're done!

The nice thing about having a CL option to run them this way is that you can monitor your progress towards "done", but you can also run the specs in isolation normally. This gives you the benefits of both worlds - isolation and integration. In fact the mock modes could be isolation (default), verification and integration. That has some nice symmetry to it.

Thoughts?

David

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

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

From noreply at rubyforge.org  Sun Nov 18 20:28:30 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 20:28:30 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-5544 ] should_output
	(includes complete method definition)
Message-ID: <20071119012830.6412E185859A@rubyforge.org>

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

Category: None
Group: None
>Status: Closed
Priority: 3
Submitted By: Eero Saynatkari (esaynatkari)
Assigned to: Nobody (None)
Summary: should_output (includes complete method definition)

Initial Comment:
This expectation provides a way to specify program output.
It takes into account Readline which refuses to allow use
of StringIO or Tempfile. It is a bit ugly having to work
around symbolic names but seems to work fine in my code.


# Usage examples:

 lambda {UI.mainloop {|ui| ui.output 'foo'}}.should_output "foo\n"
 lambda {UI.mainloop {|ui| ui.output 'foo'}}.should_output /foo\n/

 lambda {UI.mainloop {|ui| ui.error 'foo'}}.should_output "foo\n", :to => '$stderr'

# Code:

# Modify RSpec a little
module Spec
  class ShouldHelper

    # Verify output from block is expected
    def output(expected, io = {:to => '$stdout'})
      to = io[:to]

      # Store the old stream
      eval "old_to = #{to}"

      # Replace, work around Readline
      eval %{
        #{to} = if $LOADED_FEATURES.grep(/readline/i).empty?
                  StringIO.new ''
                else
                  File.open '/tmp/rspec_output_#{$$}', 'w+'
                end                   # if readline
      }                               # eval
       
      @target.call 
      eval(to).rewind
      output = eval(to).read 

      # Match up
      case expected
        when Regexp
          output.should_match expected
        else 
          output.should_equal expected
      end                             # case expected
      
    # Clean up
    ensure
      eval %{
        #{to}, old_to = old_to, #{to}
        
        if old_to and old_to.kind_of? File
          require 'fileutils'
          old_to.close 
          FileUtils.rm_rf old_to.path
        end                           # if old_to
      }                               # eval
      false
    end                               # output()
  end                                 # ShouldHelper
end                                   # Spec


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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 01:23

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/19-5544-should_output-includes-complete-method-definition#ticket-19-2

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

Comment By: David Chelimsky (dchelimsky)
Date: 2006-10-26 15:58

Message:
Eero - I like this idea a lot. Would you consider submitting this as a patch against the trunk (pls indicate the revision number against which you are patching) including specs written in rspec.

Thanks,
David

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2006-08-29 12:04

Message:
Looks good, but where is the test case for this?


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

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

From noreply at rubyforge.org  Sun Nov 18 20:28:48 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 20:28:48 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-5800 ] Make QuickRef.pdf
	part of the website
Message-ID: <20071119012848.DFF93185859C@rubyforge.org>

Feature Requests item #5800, was opened at 2006-09-18 21:48
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5800&group_id=797

Category: None
Group: None
>Status: Closed
Priority: 3
Submitted By: Aslak Helles?y (aslak_hellesoy)
Assigned to: Nobody (None)
Summary: Make QuickRef.pdf part of the website

Initial Comment:
The pdf must be moved to doc/src, a link must be created somewhere and we must make sure it's copied over to doc/output as part of the build

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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 01:26

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/20-5800-make-quickref-pdf-part-of-the-website#ticket-20-2

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-04-17 15:49

Message:
Yeah - the synatax on that pdf is really outdated.  If you don't have the source just delete it and close the ticket.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-04-17 01:09

Message:
Actually, I think we should remove it since we don't have the source so we can update it.

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

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

From noreply at rubyforge.org  Sun Nov 18 20:34:54 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 20:34:54 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-6059 ] Controller testing w/
	Rails: response is not upated when same action is GETted
	multiple times within a specify block
Message-ID: <20071119013454.BAFD4185859A@rubyforge.org>

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

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: David Lee (davidlee)
Assigned to: Nobody (None)
Summary: Controller testing w/ Rails: response is not upated when same action is GETted multiple times within a specify block

Initial Comment:
Controller testing with RSpec + Rails: response is not upated within a specification when same action is called multiple times within a specify block

using Rails 1.1.6 and RSpec 0.6.4

The response object is not being updated within a specify block if multiple responses are generated by GETting the same action. 

This was verified by checking the redirect_url reported.

This does not appear to be an issue unless the *same action* is called multiple times within a specify block, eg to test the effect of accessing an action with different permissions or parameters. Calling the action with different parameters did not appear to affect the problem.

example:

  specify "Index should redirect to welcome if already logged in" do

    # this will redirect to login as user is not logged in.
    # the presence of this line will break the test.
    get :index 

    request.session[:user] = 1 # subsequent gets will redirect to welcome
   
    # this will be ignored with regard to the response.redirect_url reported
    get :index 
    response.should_redirect

    # fails if first line is present:
    # says the redirect_url equals 'http://test.host/account/login'
    # which is a leftover from the first get :index
    response.redirect_url.should_equal 'http://test.host/account/welcome'
  end

breaking the two `get :index` calls out into separate specify blocks alleviates the problem.


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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 20:34

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/21-6059-controller-testing-w-rails-response-is-not-upated-when-same-action-is-getted-multiple-times-within-a-specify-block#ticket-21-2

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

Comment By: Assaf Arkin (assaf)
Date: 2007-09-12 19:50

Message:
Given
  GET request returning Last-Modified
When
  GET request uses it as If-Unmodified-Since
Then
  304 (Not Modified)

But due to this design, I'm going to receive 200 the second time.  Note that I don't care to mock the value of Last-Modified, this is the expected behavior of the controller.


Or:

Given
  PUT entity in resource
When
  GET entity from resource
Then
  200 (OK)
  and entities are equivalent

But if PUT returns 201 (Created), then so will GET.  Again, I do not care to mock the model, it's too much work to get the model to match the output, when neither mock nor model are the behavior I'm testing here.


I think controller specs that can only issue one request are too fine grained.  It's the equivalent of model specs where you can create or find or update, but not do both in a single sequence.

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

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

Message:
Also - moving this over to feature requests - this is by design, not a bug.

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

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

Message:
"breaking the two `get :index` calls out into separate specify blocks alleviates the problem."

That's also the BDD way.

Given (context)
When (single event or set of events)
Then (outcomes)

The specs could read:

Given a user who is logged in
- GET index should redirect to welcome

Given a user who is NOT logged in
- GET index should redirect to login page

OR you could have two specs in the same context:

GET index
- should redirect a logged in user to welcome
- should redirect an anonymous user to the login page

We will need to support multiple GETS when we add integration specs, so I'll leave this open to keep it on the radar, but we will likely not be supporting this in the context of controller specs.

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

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

From noreply at rubyforge.org  Sun Nov 18 20:35:21 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 20:35:21 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-6059 ] Controller testing w/
	Rails: response is not upated when same action is GETted
	multiple times within a specify block
Message-ID: <20071119013521.EE369185859A@rubyforge.org>

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

Category: None
Group: None
>Status: Closed
Priority: 3
Submitted By: David Lee (davidlee)
Assigned to: Nobody (None)
Summary: Controller testing w/ Rails: response is not upated when same action is GETted multiple times within a specify block

Initial Comment:
Controller testing with RSpec + Rails: response is not upated within a specification when same action is called multiple times within a specify block

using Rails 1.1.6 and RSpec 0.6.4

The response object is not being updated within a specify block if multiple responses are generated by GETting the same action. 

This was verified by checking the redirect_url reported.

This does not appear to be an issue unless the *same action* is called multiple times within a specify block, eg to test the effect of accessing an action with different permissions or parameters. Calling the action with different parameters did not appear to affect the problem.

example:

  specify "Index should redirect to welcome if already logged in" do

    # this will redirect to login as user is not logged in.
    # the presence of this line will break the test.
    get :index 

    request.session[:user] = 1 # subsequent gets will redirect to welcome
   
    # this will be ignored with regard to the response.redirect_url reported
    get :index 
    response.should_redirect

    # fails if first line is present:
    # says the redirect_url equals 'http://test.host/account/login'
    # which is a leftover from the first get :index
    response.redirect_url.should_equal 'http://test.host/account/welcome'
  end

breaking the two `get :index` calls out into separate specify blocks alleviates the problem.


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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 01:34

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/21-6059-controller-testing-w-rails-response-is-not-upated-when-same-action-is-getted-multiple-times-within-a-specify-block#ticket-21-2

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

Comment By: Assaf Arkin (assaf)
Date: 2007-09-12 23:50

Message:
Given
  GET request returning Last-Modified
When
  GET request uses it as If-Unmodified-Since
Then
  304 (Not Modified)

But due to this design, I'm going to receive 200 the second time.  Note that I don't care to mock the value of Last-Modified, this is the expected behavior of the controller.


Or:

Given
  PUT entity in resource
When
  GET entity from resource
Then
  200 (OK)
  and entities are equivalent

But if PUT returns 201 (Created), then so will GET.  Again, I do not care to mock the model, it's too much work to get the model to match the output, when neither mock nor model are the behavior I'm testing here.


I think controller specs that can only issue one request are too fine grained.  It's the equivalent of model specs where you can create or find or update, but not do both in a single sequence.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2006-11-07 11:02

Message:
Also - moving this over to feature requests - this is by design, not a bug.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2006-11-07 11:02

Message:
"breaking the two `get :index` calls out into separate specify blocks alleviates the problem."

That's also the BDD way.

Given (context)
When (single event or set of events)
Then (outcomes)

The specs could read:

Given a user who is logged in
- GET index should redirect to welcome

Given a user who is NOT logged in
- GET index should redirect to login page

OR you could have two specs in the same context:

GET index
- should redirect a logged in user to welcome
- should redirect an anonymous user to the login page

We will need to support multiple GETS when we add integration specs, so I'll leave this open to keep it on the radar, but we will likely not be supporting this in the context of controller specs.

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

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

From noreply at rubyforge.org  Sun Nov 18 20:35:59 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 20:35:59 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-6397 ] Support headers and
	session variables in http requests
Message-ID: <20071119013559.D05611858598@rubyforge.org>

Feature Requests item #6397, was opened at 2006-10-30 03:17
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6397&group_id=797

Category: rails plugin
Group: None
Status: Open
Priority: 3
Submitted By: Jeff Dean (jefdean)
Assigned to: Nobody (None)
Summary: Support headers and session variables in http requests

Initial Comment:
[the following is a duplicate comment from one I posted on the mailing list because rubyforge logins were down for a while...]

I'd love to see better support for specifying headers headers and session variables to the http requests - something like:

_verb_(action, parameters=nil, session_vars=nil, headers=nil)

This way we could write:
get(:index, {:id=>1}, {:user=>@user}, {:accept=>'application/...'})

Or add some syntactic sugar such as:
get(:index, {}, {}, {:format=>:js})

to simulate xml/javascript/mobile device formats.

I'll start working on this shortly unless anyone else has the time to do it easily and quickly.

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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 20:35

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/22-6397-support-headers-and-session-variables-in-http-requests#ticket-22-2

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

Comment By: Assaf Arkin (assaf)
Date: 2007-09-12 19:30

Message:
Sessions and headers would be a nice addition.

In controller specs, get/post/etc bypass CgiRequest which handles headers and content decoding, so if you want to specify the format, pass :format=>'json' as a parameter, not header.


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

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

Message:
Noone has been working on it. Feel free to contribute a patch. 

Since I last commented on this issue RSpec no longer depends on zentest.

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

Comment By: Douglas Tan (bianster)
Date: 2007-05-14 10:45

Message:
Has any progress been made regarding this? I'll like to help with implementing the feature.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2006-10-30 19:24

Message:
I don't think anyone is working on it. Make sure you submit specs too :-)
I haven't looked into the details, but you might actually have to patch zentest, since rspec on rails builds on it.

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

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

From noreply at rubyforge.org  Sun Nov 18 20:36:58 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 20:36:58 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-6440 ] Validate RSpec on
	Rails with RCov
Message-ID: <20071119013658.2B497185859A@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Priority: 3
Submitted By: Aslak Helles?y (aslak_hellesoy)
Assigned to: Nobody (None)
Summary: Validate RSpec on Rails with RCov

Initial Comment:
Just like with core, we should measure the coverage of RSpec on Rails (example code and the stuff in lib) and verify that it is 100% covered

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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 20:36

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/23-6440-validate-rspec-on-rails-with-rcov

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

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

From noreply at rubyforge.org  Sun Nov 18 20:37:29 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 20:37:29 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-6440 ] Validate RSpec on
	Rails with RCov
Message-ID: <20071119013729.99E98185859A@rubyforge.org>

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

Category: rails plugin
Group: None
>Status: Closed
Priority: 3
Submitted By: Aslak Helles?y (aslak_hellesoy)
Assigned to: Nobody (None)
Summary: Validate RSpec on Rails with RCov

Initial Comment:
Just like with core, we should measure the coverage of RSpec on Rails (example code and the stuff in lib) and verify that it is 100% covered

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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 01:36

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/23-6440-validate-rspec-on-rails-with-rcov

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

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

From noreply at rubyforge.org  Sun Nov 18 20:37:47 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 20:37:47 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-6397 ] Support headers and
	session variables in http requests
Message-ID: <20071119013747.C103C1858598@rubyforge.org>

Feature Requests item #6397, was opened at 2006-10-30 08:17
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6397&group_id=797

Category: rails plugin
Group: None
>Status: Closed
Priority: 3
Submitted By: Jeff Dean (jefdean)
Assigned to: Nobody (None)
Summary: Support headers and session variables in http requests

Initial Comment:
[the following is a duplicate comment from one I posted on the mailing list because rubyforge logins were down for a while...]

I'd love to see better support for specifying headers headers and session variables to the http requests - something like:

_verb_(action, parameters=nil, session_vars=nil, headers=nil)

This way we could write:
get(:index, {:id=>1}, {:user=>@user}, {:accept=>'application/...'})

Or add some syntactic sugar such as:
get(:index, {}, {}, {:format=>:js})

to simulate xml/javascript/mobile device formats.

I'll start working on this shortly unless anyone else has the time to do it easily and quickly.

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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 01:35

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/22-6397-support-headers-and-session-variables-in-http-requests#ticket-22-2

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

Comment By: Assaf Arkin (assaf)
Date: 2007-09-12 23:30

Message:
Sessions and headers would be a nice addition.

In controller specs, get/post/etc bypass CgiRequest which handles headers and content decoding, so if you want to specify the format, pass :format=>'json' as a parameter, not header.


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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-05-14 15:16

Message:
Noone has been working on it. Feel free to contribute a patch. 

Since I last commented on this issue RSpec no longer depends on zentest.

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

Comment By: Douglas Tan (bianster)
Date: 2007-05-14 14:45

Message:
Has any progress been made regarding this? I'll like to help with implementing the feature.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2006-10-31 00:24

Message:
I don't think anyone is working on it. Make sure you submit specs too :-)
I haven't looked into the details, but you might actually have to patch zentest, since rspec on rails builds on it.

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

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

From noreply at rubyforge.org  Sun Nov 18 20:38:08 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 20:38:08 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-6523 ] Run rspec on rails
	without a db
Message-ID: <20071119013808.1B4611858598@rubyforge.org>

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

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Paul Pagel (paulwpagel)
Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: Run rspec on rails without a db

Initial Comment:
We need to be able to run the specs without the database.  We have no model objects in some of our projects, therefore, no use for the db.

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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 20:38

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/24-6523-run-rspec-on-rails-without-a-db#ticket-24-2

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

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

Message:
I'm reopening this because it's currently broken.

I think we should support unit_record by sensing for DisconnectedModel and not running all the Rails setup commands if it is found.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-04-04 05:49

Message:
Fixed in /branches/0.9-dev#1689

If you remove config/database.yml from your Rails project, the various spec:* rake tasks will no longer depend on db:test:prepare.

Further, you should tell Rails not to use AR in your config/environment.rb file



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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-04-01 10:08

Message:
Now that we have a cleaner configuration model, we should add a configuration option to do this:

Spec::Runner.configure do |config|
  config.use_database = false
end

(or something like that)

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2006-11-06 20:28

Message:
How do I reproduce this missing feature? How would you like it to work exactly? Code please.

http://rspec.rubyforge.org/contribute.html

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

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

From noreply at rubyforge.org  Sun Nov 18 20:39:02 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 20:39:02 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-6523 ] Run rspec on rails
	without a db
Message-ID: <20071119013902.5E0D71858598@rubyforge.org>

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

Category: None
Group: None
>Status: Closed
Priority: 3
Submitted By: Paul Pagel (paulwpagel)
Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: Run rspec on rails without a db

Initial Comment:
We need to be able to run the specs without the database.  We have no model objects in some of our projects, therefore, no use for the db.

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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 01:38

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/24-6523-run-rspec-on-rails-without-a-db#ticket-24-2

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-27 12:10

Message:
I'm reopening this because it's currently broken.

I think we should support unit_record by sensing for DisconnectedModel and not running all the Rails setup commands if it is found.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-04-04 09:49

Message:
Fixed in /branches/0.9-dev#1689

If you remove config/database.yml from your Rails project, the various spec:* rake tasks will no longer depend on db:test:prepare.

Further, you should tell Rails not to use AR in your config/environment.rb file



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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-04-01 14:08

Message:
Now that we have a cleaner configuration model, we should add a configuration option to do this:

Spec::Runner.configure do |config|
  config.use_database = false
end

(or something like that)

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2006-11-07 01:28

Message:
How do I reproduce this missing feature? How would you like it to work exactly? Code please.

http://rspec.rubyforge.org/contribute.html

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

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

From noreply at rubyforge.org  Sun Nov 18 20:39:21 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 20:39:21 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-6578 ] Integrate
	SeleniumOnRails with rspec_selenium support
Message-ID: <20071119013921.568321858598@rubyforge.org>

Feature Requests item #6578, was opened at 2006-11-08 18:11
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6578&group_id=797

Category: rails plugin
Group: None
Status: Open
Priority: 3
Submitted By: Jay Levitt (jaylev)
Assigned to: Nobody (None)
Summary: Integrate SeleniumOnRails with rspec_selenium support

Initial Comment:
The idea of rspec's Selenium support is nice, but SeleniumOnRails provides some great features including the testrunner console, fixture loading, table clearing, etc.  I don't know how feasible it is to integrate, since SOR uses Selenium-Core, and rspec currently uses Selenium-RC.  But it's my feature request and so I get to ask for it.

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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 20:39

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/25-http-rubyforge-org-tracker-index-php-func-detail-aid-6578-group_id-797-atid-3152#ticket-25-3



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

Comment By: Jay Levitt (jaylev)
Date: 2006-11-16 16:18

Message:
There's no way to provide code for some of these, but I'll
give you some stories instead.  

1. Selenium on Rails provides a controller (added only in
the test environment) that lets me:

- load fixtures 
- clear specific tables
- clear the session hash

This is necessary because rspec's usual transactional
fixtures can't work when rspec's running in a different
process than the web server that the browser talks to.

2. SOR lets me see the progress of the test, and stops on
the failed screen if a test fails.  For some reason, even
though the rest of rspec doesn't (can't) provide such a
feature, I really missed this in the Selenium support; rspec
closes the browser whether or not the test succeeds.

3. SOR provides a "test runner" control panel to control the
speed of execution, let me run specific tests, etc.  Perhaps
a --walk option along with the new --line feature would
suffice here.

4. SOR provides some nice Javascript magic that shows the
test itself in a frame, and turns each step of the test
green when it's executed.

5. I think the 'keep the browser open' patch should be
integrated as a command-line or runtime option.

These are listed in roughly the order I care about them; #1
and #2 especially are preventing me from switching from SOR
to rspec's inbuilt support.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2006-11-13 13:41

Message:
What kind of integration are you looking for? You have to be more specific. Code please.

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

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

From noreply at rubyforge.org  Sun Nov 18 20:40:03 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 20:40:03 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-6578 ] Integrate
	SeleniumOnRails with rspec_selenium support
Message-ID: <20071119014003.980191858598@rubyforge.org>

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

Category: rails plugin
Group: None
>Status: Closed
Priority: 3
Submitted By: Jay Levitt (jaylev)
Assigned to: Nobody (None)
Summary: Integrate SeleniumOnRails with rspec_selenium support

Initial Comment:
The idea of rspec's Selenium support is nice, but SeleniumOnRails provides some great features including the testrunner console, fixture loading, table clearing, etc.  I don't know how feasible it is to integrate, since SOR uses Selenium-Core, and rspec currently uses Selenium-RC.  But it's my feature request and so I get to ask for it.

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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 01:39

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/25-http-rubyforge-org-tracker-index-php-func-detail-aid-6578-group_id-797-atid-3152#ticket-25-3



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

Comment By: Jay Levitt (jaylev)
Date: 2006-11-16 21:18

Message:
There's no way to provide code for some of these, but I'll
give you some stories instead.  

1. Selenium on Rails provides a controller (added only in
the test environment) that lets me:

- load fixtures 
- clear specific tables
- clear the session hash

This is necessary because rspec's usual transactional
fixtures can't work when rspec's running in a different
process than the web server that the browser talks to.

2. SOR lets me see the progress of the test, and stops on
the failed screen if a test fails.  For some reason, even
though the rest of rspec doesn't (can't) provide such a
feature, I really missed this in the Selenium support; rspec
closes the browser whether or not the test succeeds.

3. SOR provides a "test runner" control panel to control the
speed of execution, let me run specific tests, etc.  Perhaps
a --walk option along with the new --line feature would
suffice here.

4. SOR provides some nice Javascript magic that shows the
test itself in a frame, and turns each step of the test
green when it's executed.

5. I think the 'keep the browser open' patch should be
integrated as a command-line or runtime option.

These are listed in roughly the order I care about them; #1
and #2 especially are preventing me from switching from SOR
to rspec's inbuilt support.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2006-11-13 18:41

Message:
What kind of integration are you looking for? You have to be more specific. Code please.

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

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

From noreply at rubyforge.org  Sun Nov 18 20:40:08 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 20:40:08 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-6595 ] RcovHtmlFormatter
Message-ID: <20071119014008.C619B18585A3@rubyforge.org>

Feature Requests item #6595, was opened at 2006-11-09 21:28
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6595&group_id=797

Category: RSpec.tmbundle
Group: None
Status: Open
Priority: 3
Submitted By: Aslak Helles?y (aslak_hellesoy)
Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: RcovHtmlFormatter

Initial Comment:
It would work in a similar way to TextMateFormatter, except it would link to an RCov HTML report (at the right line). This would probably rely on an environment variable to get the relative path from the HTML to the RCov report.

Useful for bigger projects in a CI environment. Some of the linking code in TextMateFormatter should be factored back to HtmlFormatter.

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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 20:40

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/26-6595-rcovhtmlformatter

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

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

From noreply at rubyforge.org  Sun Nov 18 20:40:37 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 20:40:37 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-6595 ] RcovHtmlFormatter
Message-ID: <20071119014037.9096C1858598@rubyforge.org>

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

Category: RSpec.tmbundle
Group: None
>Status: Closed
Priority: 3
Submitted By: Aslak Helles?y (aslak_hellesoy)
Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: RcovHtmlFormatter

Initial Comment:
It would work in a similar way to TextMateFormatter, except it would link to an RCov HTML report (at the right line). This would probably rely on an environment variable to get the relative path from the HTML to the RCov report.

Useful for bigger projects in a CI environment. Some of the linking code in TextMateFormatter should be factored back to HtmlFormatter.

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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 01:40

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/26-6595-rcovhtmlformatter

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

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

From noreply at rubyforge.org  Sun Nov 18 20:57:47 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 20:57:47 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-6651 ] Ability to query
	whether a spec has failed or not in teardown
Message-ID: <20071119015747.4B1861858598@rubyforge.org>

Feature Requests item #6651, was opened at 2006-11-13 13:39
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6651&group_id=797

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Aslak Helles?y (aslak_hellesoy)
Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: Ability to query whether a spec has failed or not in teardown

Initial Comment:
I'm using RSpec to drive Watir. When a spec fails, I want to take a screenshot before closing the browser in teardown. (Screenshotting is supported by Watir). Example:

teardown do
  if failed?
    screenshot_file_name = "#{context_name} #{spec_name}.jpg".gsub!(/\s/, "_")
    screen_capture(screenshot, true)
  end
  @ie.close
end

3 new methods that need to be available in teardown:

failed?
context_name
spec_name


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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 20:57

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/27-6651-ability-to-query-whether-a-spec-has-failed-or-not-in-teardown#ticket-27-2

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-01-31 07:32

Message:
It's not doc'd on the website because it's not really an RSpec feature. It's a library that we've forked into RSpec in order to avoid the dependency.

There is rdoc in the callback dirs - check it out and see if you find it sufficient or not.

That said, Brian, can you please enlighten us as to how to use the before_setup and after_teardown callbacks to solve Aslak's seemingly-former-problem.

Thanks,
David

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

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

Message:
I never got it resolved because I couldn't easily figure out how to use the callback stuff (no docs).

Further, I realised I didn't really need it. I thought I needed it in spec/ui to decide whether or not to take a screenshot (for failing specs), but realized I can always take a screenshot in teardown, regardless of whether the spec failed.

Therefore, I'm not sure we need the callback stuff at all in RSpec - it doesn't seem to solve any real problems - at least not that I'm aware of. As far as I am concerned it is a non-feature because it's not documented.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-01-30 19:05

Message:
Aslak - did this one got resolved w/ the addition of callbacks? If so, can we kill it?

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

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

From noreply at rubyforge.org  Sun Nov 18 20:58:04 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 20:58:04 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-6651 ] Ability to query
	whether a spec has failed or not in teardown
Message-ID: <20071119015804.CB969185859A@rubyforge.org>

Feature Requests item #6651, was opened at 2006-11-13 18:39
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6651&group_id=797

Category: None
Group: None
>Status: Closed
Priority: 3
Submitted By: Aslak Helles?y (aslak_hellesoy)
Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: Ability to query whether a spec has failed or not in teardown

Initial Comment:
I'm using RSpec to drive Watir. When a spec fails, I want to take a screenshot before closing the browser in teardown. (Screenshotting is supported by Watir). Example:

teardown do
  if failed?
    screenshot_file_name = "#{context_name} #{spec_name}.jpg".gsub!(/\s/, "_")
    screen_capture(screenshot, true)
  end
  @ie.close
end

3 new methods that need to be available in teardown:

failed?
context_name
spec_name


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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 01:57

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/27-6651-ability-to-query-whether-a-spec-has-failed-or-not-in-teardown#ticket-27-2

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-01-31 12:32

Message:
It's not doc'd on the website because it's not really an RSpec feature. It's a library that we've forked into RSpec in order to avoid the dependency.

There is rdoc in the callback dirs - check it out and see if you find it sufficient or not.

That said, Brian, can you please enlighten us as to how to use the before_setup and after_teardown callbacks to solve Aslak's seemingly-former-problem.

Thanks,
David

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-01-31 10:18

Message:
I never got it resolved because I couldn't easily figure out how to use the callback stuff (no docs).

Further, I realised I didn't really need it. I thought I needed it in spec/ui to decide whether or not to take a screenshot (for failing specs), but realized I can always take a screenshot in teardown, regardless of whether the spec failed.

Therefore, I'm not sure we need the callback stuff at all in RSpec - it doesn't seem to solve any real problems - at least not that I'm aware of. As far as I am concerned it is a non-feature because it's not documented.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-01-31 00:05

Message:
Aslak - did this one got resolved w/ the addition of callbacks? If so, can we kill it?

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

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

From noreply at rubyforge.org  Sun Nov 18 20:58:34 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 20:58:34 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-6791 ] stub return values
	for all instances of a class
Message-ID: <20071119015834.B16751858598@rubyforge.org>

Feature Requests item #6791, was opened at 2006-11-20 11:50
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6791&group_id=797

Category: mock module
Group: None
Status: Open
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Nobody (None)
Summary: stub return values for all instances of a class

Initial Comment:
I'd like to be able to do this:

SomeClass.stub_instance_method!(:method_name).and_return(specified_value)

(syntax just a suggestion)

This should set up a world in which all instances of SomeClass return specified_value for any calls to :method_name.

This differs from SomeClass.stub! in that it applies to instance methods rather than class methods.

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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 20:58

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/28-6791-stub-return-values-for-all-instances-of-a-class#ticket-28-2

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

Comment By: Carl Porth (badcarl)
Date: 2007-07-18 18:49

Message:
I'd also like to be able to do this:

SomeClass.new_instances do |instance|
  instance.stub!(:method_name_1).and_return(:value_1)
  instance.stub!(:method_name_2).and_return(:value_2)
end

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

Comment By: Chris Anderson (jchris)
Date: 2007-01-17 20:29

Message:
Found a solution to my specific problem:


def login_stub(user)

  controller.stub!(:current_user).and_return(user)

end


Just in case someone happens by from a google search etc.

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

Comment By: Chris Anderson (jchris)
Date: 2007-01-17 18:24

Message:
I agree. I'm trying to stub a login_as method for controller specs that won't rely on the database. I'd like to have any instance of ApplicationController stub :current_user and return my mock user. But this doesn't seem possible with the current library. Mocha has the feature, so I may lean on it for the time being.

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

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

From noreply at rubyforge.org  Sun Nov 18 20:59:28 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 20:59:28 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-7410 ] support for
	pre_loaded_fixtures
Message-ID: <20071119015928.A06A31858598@rubyforge.org>

Feature Requests item #7410, was opened at 2006-12-21 02:56
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=7410&group_id=797

Category: rails plugin
Group: None
Status: Open
Priority: 3
Submitted By: Jens-Christian Fischer (jcfischer)
Assigned to: Nobody (None)
Summary: support for pre_loaded_fixtures

Initial Comment:
I have a project that uses pre_loaded_fixtures in it's test cases. I tried to use rspec 0.7.5 with it, but it fails with a Runtime Error from the fixtures classes ("Load fixtures before instantiating them")

I made  "pre_loaded_fixtures" available through an accessor (like the instantiated_fixtures etc.) but I'm stuck at that point.

I looked through the fixtures.rb file to tried and understand the behaviour, but I don't grok it. Anyone out there with more fixtures-fu that could point me in the right direction, so that I can create a patch?

thanks
Jens-Christian 

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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 20:59

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/29-7410-support-for-pre_loaded_fixtures

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

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

From noreply at rubyforge.org  Sun Nov 18 21:01:15 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 21:01:15 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-6791 ] stub return values
	for all instances of a class
Message-ID: <20071119020115.CE99C185859A@rubyforge.org>

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

Category: mock module
Group: None
>Status: Closed
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Nobody (None)
Summary: stub return values for all instances of a class

Initial Comment:
I'd like to be able to do this:

SomeClass.stub_instance_method!(:method_name).and_return(specified_value)

(syntax just a suggestion)

This should set up a world in which all instances of SomeClass return specified_value for any calls to :method_name.

This differs from SomeClass.stub! in that it applies to instance methods rather than class methods.

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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 01:58

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/28-6791-stub-return-values-for-all-instances-of-a-class#ticket-28-2

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

Comment By: Carl Porth (badcarl)
Date: 2007-07-18 22:49

Message:
I'd also like to be able to do this:

SomeClass.new_instances do |instance|
  instance.stub!(:method_name_1).and_return(:value_1)
  instance.stub!(:method_name_2).and_return(:value_2)
end

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

Comment By: Chris Anderson (jchris)
Date: 2007-01-18 01:29

Message:
Found a solution to my specific problem:


def login_stub(user)

  controller.stub!(:current_user).and_return(user)

end


Just in case someone happens by from a google search etc.

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

Comment By: Chris Anderson (jchris)
Date: 2007-01-17 23:24

Message:
I agree. I'm trying to stub a login_as method for controller specs that won't rely on the database. I'd like to have any instance of ApplicationController stub :current_user and return my mock user. But this doesn't seem possible with the current library. Mocha has the feature, so I may lean on it for the time being.

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

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

From noreply at rubyforge.org  Sun Nov 18 21:01:34 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 21:01:34 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-7410 ] support for
	pre_loaded_fixtures
Message-ID: <20071119020134.7BDEF1858598@rubyforge.org>

Feature Requests item #7410, was opened at 2006-12-21 07:56
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=7410&group_id=797

Category: rails plugin
Group: None
>Status: Closed
Priority: 3
Submitted By: Jens-Christian Fischer (jcfischer)
Assigned to: Nobody (None)
Summary: support for pre_loaded_fixtures

Initial Comment:
I have a project that uses pre_loaded_fixtures in it's test cases. I tried to use rspec 0.7.5 with it, but it fails with a Runtime Error from the fixtures classes ("Load fixtures before instantiating them")

I made  "pre_loaded_fixtures" available through an accessor (like the instantiated_fixtures etc.) but I'm stuck at that point.

I looked through the fixtures.rb file to tried and understand the behaviour, but I don't grok it. Anyone out there with more fixtures-fu that could point me in the right direction, so that I can create a patch?

thanks
Jens-Christian 

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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 01:59

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/29-7410-support-for-pre_loaded_fixtures

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

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

From noreply at rubyforge.org  Sun Nov 18 21:03:56 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 21:03:56 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-7536 ] Mock expectations can
	be called more than once and ordered
Message-ID: <20071119020356.57D1D1858598@rubyforge.org>

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

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: Mock expectations can be called more than once and ordered

Initial Comment:
the_mock = mock("the_mock")
the_mock.should_receive(:foo).ordered
the_mock.should_receive(:bar).ordered
the_mock.should_receive(:foo).ordered
the_mock.should_receive(:baz).ordered


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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 21:03

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/30-7536-mock-expectations-can-be-called-more-than-once-and-ordered#ticket-30-2

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

Comment By: Brian Takita (btakita)
Date: 2007-01-05 02:13

Message:
require "rubygems"
require "spec"

context "An Ordered mock" do
  specify "should allow a method to be ordered twice" do
    the_mock = mock("the_mock")
    the_mock.should_receive(:foo).ordered
    the_mock.should_receive(:bar).ordered
    the_mock.should_receive(:foo).ordered
    the_mock.should_receive(:baz).ordered

    the_mock.foo
    the_mock.bar
    the_mock.foo
    the_mock.baz
  end
end


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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-01-02 19:17

Message:
Do you have a failing spec?

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

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

From noreply at rubyforge.org  Sun Nov 18 21:04:20 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 21:04:20 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-7536 ] Mock expectations can
	be called more than once and ordered
Message-ID: <20071119020420.1D1301858598@rubyforge.org>

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

Category: None
Group: None
>Status: Closed
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: Mock expectations can be called more than once and ordered

Initial Comment:
the_mock = mock("the_mock")
the_mock.should_receive(:foo).ordered
the_mock.should_receive(:bar).ordered
the_mock.should_receive(:foo).ordered
the_mock.should_receive(:baz).ordered


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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 02:03

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/30-7536-mock-expectations-can-be-called-more-than-once-and-ordered#ticket-30-2

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

Comment By: Brian Takita (btakita)
Date: 2007-01-05 07:13

Message:
require "rubygems"
require "spec"

context "An Ordered mock" do
  specify "should allow a method to be ordered twice" do
    the_mock = mock("the_mock")
    the_mock.should_receive(:foo).ordered
    the_mock.should_receive(:bar).ordered
    the_mock.should_receive(:foo).ordered
    the_mock.should_receive(:baz).ordered

    the_mock.foo
    the_mock.bar
    the_mock.foo
    the_mock.baz
  end
end


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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-01-03 00:17

Message:
Do you have a failing spec?

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

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

From noreply at rubyforge.org  Sun Nov 18 21:07:35 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 21:07:35 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-8001 ] separate out routing
	specs
Message-ID: <20071119020735.9E2891858598@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Nobody (None)
Summary: separate out routing specs

Initial Comment:
Routing happens outside of controllers and should be spec'able separately from controllers. This should be either part of a higher level integration spec or Story Runner, OR should be a new component category parallel w/ models, views, controllers and helpers.

Routing specs should support both route processing and route generation. For example:

route_for(:controller => "people", :action => "edit", :id => 1).should == "/people/1;edit"

AND

"/people/1;edit".should route_to(:controller => "people", :action => "edit", :id => 1)

The latter example would be extremely useful for custom mappings like this:

"/".should route_to(:controller => 'welcome')


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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 21:07

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/31-8001-separate-out-routing-specs#ticket-31-2

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

Comment By: Rupert Voelcker (rupert)
Date: 2007-10-04 16:46

Message:
you can actually specify routes the other way round using params_from with the following syntax:

params_from(:get, '/people/1/edit').should == {:controller => "people", :action => "edit", :id => "1"}

although route_to is a bit more suggestive of what it does. Then perhaps route_from should be aliased to route_for so there's a route_to and a route_from.

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

Comment By: Matt Scilipoti (mattscilipoti)
Date: 2007-10-04 13:00

Message:
+1.  This looks like a good format to me.

Note: On edge, url format has changed from "/people/1;edit" to "/people/1/edit"

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-01-19 11:34

Message:
I'd LOVE to take credit for it, but it comes from a comment by Eric Peden to [#6541]:

http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6541&group_id=797

Thanks for the idea Eric!

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-01-19 10:00

Message:
I LOVE that idea.

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

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

From noreply at rubyforge.org  Sun Nov 18 21:08:04 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 21:08:04 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-8001 ] separate out routing
	specs
Message-ID: <20071119020804.442621858598@rubyforge.org>

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

Category: rails plugin
Group: None
>Status: Closed
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Nobody (None)
Summary: separate out routing specs

Initial Comment:
Routing happens outside of controllers and should be spec'able separately from controllers. This should be either part of a higher level integration spec or Story Runner, OR should be a new component category parallel w/ models, views, controllers and helpers.

Routing specs should support both route processing and route generation. For example:

route_for(:controller => "people", :action => "edit", :id => 1).should == "/people/1;edit"

AND

"/people/1;edit".should route_to(:controller => "people", :action => "edit", :id => 1)

The latter example would be extremely useful for custom mappings like this:

"/".should route_to(:controller => 'welcome')


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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 02:07

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/31-8001-separate-out-routing-specs#ticket-31-2

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

Comment By: Rupert Voelcker (rupert)
Date: 2007-10-04 20:46

Message:
you can actually specify routes the other way round using params_from with the following syntax:

params_from(:get, '/people/1/edit').should == {:controller => "people", :action => "edit", :id => "1"}

although route_to is a bit more suggestive of what it does. Then perhaps route_from should be aliased to route_for so there's a route_to and a route_from.

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

Comment By: Matt Scilipoti (mattscilipoti)
Date: 2007-10-04 17:00

Message:
+1.  This looks like a good format to me.

Note: On edge, url format has changed from "/people/1;edit" to "/people/1/edit"

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-01-19 16:34

Message:
I'd LOVE to take credit for it, but it comes from a comment by Eric Peden to [#6541]:

http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6541&group_id=797

Thanks for the idea Eric!

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-01-19 15:00

Message:
I LOVE that idea.

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

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

From noreply at rubyforge.org  Sun Nov 18 21:08:29 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 21:08:29 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-8424 ] more integrated email
	spec'ing support
Message-ID: <20071119020830.0247F185859A@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: David Chelimsky (dchelimsky)
Summary: more integrated email spec'ing support

Initial Comment:
Version: trunk rev 1461

Current support for email is based on assert_select. It allows you to specify html email but does not cover the following:

1. plain-text email
2. headers
3. isolation of individual email among many delivered

It also requires some special setup/teardown. It would be nice if a simple declaration like intercept_email or something like that would take care of that for you.

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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 21:08

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/32-8424-more-integrated-email-spec-ing-support

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

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

From noreply at rubyforge.org  Sun Nov 18 21:08:43 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 21:08:43 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-8424 ] more integrated email
	spec'ing support
Message-ID: <20071119020843.7CA7118585A3@rubyforge.org>

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

Category: rails plugin
Group: None
>Status: Closed
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: David Chelimsky (dchelimsky)
Summary: more integrated email spec'ing support

Initial Comment:
Version: trunk rev 1461

Current support for email is based on assert_select. It allows you to specify html email but does not cover the following:

1. plain-text email
2. headers
3. isolation of individual email among many delivered

It also requires some special setup/teardown. It would be nice if a simple declaration like intercept_email or something like that would take care of that for you.

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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 02:08

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/32-8424-more-integrated-email-spec-ing-support

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

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

From noreply at rubyforge.org  Sun Nov 18 21:10:37 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 21:10:37 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-8507 ] change #include to
	some other name
Message-ID: <20071119021037.808CD185859A@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Nobody (None)
Summary: change #include to some other name

Initial Comment:
RSpec supports inclusion of a module in a context:

context "some context" do
  include SomeModule
end

The initial intent of this was to enable state sharing across contexts and/or introduce helper methods that might be used across contexts.

Unfortunately, the use of the name "include" has led to some perception problems. It does NOT work exactly like Ruby's include does, but the name leads to the expectation that it should.

I'd like to propose that we deprecate the name "include" and replace it with some other name like "include_methods_from" or something like that (suggestions please!!!), which indicates that methods from the module will be made available, but it should not otherwise be expected to behave as Module#include behaves.

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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 21:10

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/33-8507-change-include-to-some-other-name#ticket-33-2

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-02-08 12:43

Message:
Ian - thanks for responding.


As for keeping #include, that's possible, and might be the right course. This is really a starting point for a discussion.

My concern is not a specific bug (constants), but rather that there is an expectation that it operate exactly like Module#include. Right now we see the problem with constants, but what else we see later?

Also, re: constants - I've been banging my head against a wall with it, and really don't see a way to make it work, even using const_get/set. But, my meta-fu is, well, let's say "still evolving". So if you (or anyone) has a patch to make it work, have at it!!!!

Cheers,
David

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

Comment By: Ian Dees (undees)
Date: 2007-02-08 12:00

Message:
Hmmmm.... a few ideas:

* Most of the RSpec examples use names like MyContextHelper.  So how about "helper" or some permutation?

* The context is using methods from the module -- maybe "use", "uses", "using", etc.?

* I like your "include_methods_from" because it's nice and specific, but could we use a shorter variation, like "methods_from"?

* Is there any way to salvage the old "include" method, but make it act more like the Ruby one?  Maybe with clever usage of const_get (which _does_ work inside instance_eval)?


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

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

From noreply at rubyforge.org  Sun Nov 18 21:11:19 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 21:11:19 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-8507 ] change #include to
	some other name
Message-ID: <20071119021119.B0EFD185859A@rubyforge.org>

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

Category: runner module
Group: None
>Status: Closed
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Nobody (None)
Summary: change #include to some other name

Initial Comment:
RSpec supports inclusion of a module in a context:

context "some context" do
  include SomeModule
end

The initial intent of this was to enable state sharing across contexts and/or introduce helper methods that might be used across contexts.

Unfortunately, the use of the name "include" has led to some perception problems. It does NOT work exactly like Ruby's include does, but the name leads to the expectation that it should.

I'd like to propose that we deprecate the name "include" and replace it with some other name like "include_methods_from" or something like that (suggestions please!!!), which indicates that methods from the module will be made available, but it should not otherwise be expected to behave as Module#include behaves.

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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 02:10

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/33-8507-change-include-to-some-other-name#ticket-33-2

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-02-08 17:43

Message:
Ian - thanks for responding.


As for keeping #include, that's possible, and might be the right course. This is really a starting point for a discussion.

My concern is not a specific bug (constants), but rather that there is an expectation that it operate exactly like Module#include. Right now we see the problem with constants, but what else we see later?

Also, re: constants - I've been banging my head against a wall with it, and really don't see a way to make it work, even using const_get/set. But, my meta-fu is, well, let's say "still evolving". So if you (or anyone) has a patch to make it work, have at it!!!!

Cheers,
David

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

Comment By: Ian Dees (undees)
Date: 2007-02-08 17:00

Message:
Hmmmm.... a few ideas:

* Most of the RSpec examples use names like MyContextHelper.  So how about "helper" or some permutation?

* The context is using methods from the module -- maybe "use", "uses", "using", etc.?

* I like your "include_methods_from" because it's nice and specific, but could we use a shorter variation, like "methods_from"?

* Is there any way to salvage the old "include" method, but make it act more like the Ruby one?  Maybe with clever usage of const_get (which _does_ work inside instance_eval)?


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

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

From noreply at rubyforge.org  Sun Nov 18 21:13:20 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 21:13:20 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-8509 ] Enhance controller
	docs
Message-ID: <20071119021320.A42B7185859A@rubyforge.org>

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

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Jerry West (jjw)
Assigned to: Nobody (None)
Summary: Enhance controller docs 

Initial Comment:
The controller spec docs assume some familiarity with Rails unit testing concepts . This assumption is increasingly in-appropriate as newcomers to Rails start with RSpec as their prefered development 'test' tool.

An immediate request is to update the controller specs documentation to include something like this:

Triggering controller actions

Once the expectations have been established, the controller action must be invoked.  Three helper routines are provided to emulate the HTTP GET and POST expected by the controller:

  get :action, [params]

  post :action, params

  xhr :get, :action, [params]
 
  xhr :post, :action, params

The #xhr method emulates an AJAX (xml_http_request) call.  

'params' is a hash to be placed in the params[] accessor in the controller (e.g. :id => 99, :name => 'fred', etc).  The 'action' can be either a symbol or a string.



-------

The example at the end might also be enhanced to illustrate usage.

  xhr :post, :update, :id => 3, :name => 'fred'



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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 21:13

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/34-8509-enhance-controller-docs#ticket-34-2

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-02-27 23:03

Message:
I'm inclined to reference the rails test docs rather than duplicating them in RSpec. WDYT?

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-02-08 13:24

Message:
When I created the Documentation tracker it looks like it got created as "not publicly available". Furthermore it seems that there is a bug already submitted to Rubyforge that you can't set it to public once it is set private.

http://rubyforge.org/tracker/index.php?func=detail&aid=8406&group_id=5&atid=101

So, until that bug is resolved, I'm going to move this request over to Feature Requests and we'll use that for the time being for documentation-related requests.

Cheers,
David



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

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

Message:
Lame, lame, lame. For whatever reason, if you're logged when you view http://rubyforge.org/tracker/?group_id=797, you see a Documentation tracker. If you're not, you don't.

I'll go ahead and move it myself. Please email the list if you are unable to view this item now that it's moved.

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

Comment By: Jerry West (jjw)
Date: 2007-02-08 09:41

Message:
Apologies. 

Where can I find the documentation tracker, please?  My
RubyForge Tracker tab only lists Bugs; Support Requests;
Patches and Feature Requests.  None of these have a
documentation category so far as I can see.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-02-08 09:29

Message:
Jerry - you submitted the request to Patches, but I think you intended for us to make a change rather than you submitting a patch. If this is correct, this belongs over in the Documentation tracker. If so, please try to move it there. If you have any trouble, add a comment here and I'll move it.

Cheers,
David

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-02-08 09:21

Message:
Where's the patch?

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

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

From noreply at rubyforge.org  Sun Nov 18 21:14:30 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 21:14:30 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-8509 ] Enhance controller
	docs
Message-ID: <20071119021431.100D8185859A@rubyforge.org>

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

Category: None
Group: None
>Status: Closed
Priority: 3
Submitted By: Jerry West (jjw)
Assigned to: Nobody (None)
Summary: Enhance controller docs 

Initial Comment:
The controller spec docs assume some familiarity with Rails unit testing concepts . This assumption is increasingly in-appropriate as newcomers to Rails start with RSpec as their prefered development 'test' tool.

An immediate request is to update the controller specs documentation to include something like this:

Triggering controller actions

Once the expectations have been established, the controller action must be invoked.  Three helper routines are provided to emulate the HTTP GET and POST expected by the controller:

  get :action, [params]

  post :action, params

  xhr :get, :action, [params]
 
  xhr :post, :action, params

The #xhr method emulates an AJAX (xml_http_request) call.  

'params' is a hash to be placed in the params[] accessor in the controller (e.g. :id => 99, :name => 'fred', etc).  The 'action' can be either a symbol or a string.



-------

The example at the end might also be enhanced to illustrate usage.

  xhr :post, :update, :id => 3, :name => 'fred'



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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 02:13

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/34-8509-enhance-controller-docs#ticket-34-2

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-02-28 04:03

Message:
I'm inclined to reference the rails test docs rather than duplicating them in RSpec. WDYT?

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-02-08 18:24

Message:
When I created the Documentation tracker it looks like it got created as "not publicly available". Furthermore it seems that there is a bug already submitted to Rubyforge that you can't set it to public once it is set private.

http://rubyforge.org/tracker/index.php?func=detail&aid=8406&group_id=5&atid=101

So, until that bug is resolved, I'm going to move this request over to Feature Requests and we'll use that for the time being for documentation-related requests.

Cheers,
David



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

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

Message:
Lame, lame, lame. For whatever reason, if you're logged when you view http://rubyforge.org/tracker/?group_id=797, you see a Documentation tracker. If you're not, you don't.

I'll go ahead and move it myself. Please email the list if you are unable to view this item now that it's moved.

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

Comment By: Jerry West (jjw)
Date: 2007-02-08 14:41

Message:
Apologies. 

Where can I find the documentation tracker, please?  My
RubyForge Tracker tab only lists Bugs; Support Requests;
Patches and Feature Requests.  None of these have a
documentation category so far as I can see.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-02-08 14:29

Message:
Jerry - you submitted the request to Patches, but I think you intended for us to make a change rather than you submitting a patch. If this is correct, this belongs over in the Documentation tracker. If so, please try to move it there. If you have any trouble, add a comment here and I'll move it.

Cheers,
David

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-02-08 14:21

Message:
Where's the patch?

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

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

From noreply at rubyforge.org  Sun Nov 18 21:14:32 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 21:14:32 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-8654 ] Aspects
Message-ID: <20071119021432.DE0C618585B1@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Priority: 3
Submitted By: Yurii Rashkovskii (yrashk)
Assigned to: Nobody (None)
Summary: Aspects

Initial Comment:
Specifications become a bit messy in large applications. What if implementing aspects for rspec?

context "New Document instance" do

  setup do
    @document = Document.new
  end 

   aspect "versioning" do

    specify "should have no versions" do
     @document.should_have(0).versions
    end

   end

   aspect "printing" do
     aspect "pdf" do
       ...
     end
   end

 end

New Document instance
- (versioning) should have no versions
- (printing/pdf) ...

Initial implementation (requires ActiveSupport, but could be easily ported to pure Ruby) and more details are available at http://rashkovskii.com/articles/2007/2/13/rspec-aspects

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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 21:14

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/35-8654-aspects#ticket-35-2

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-05-11 18:24

Message:
"Facet" is brilliant. Thanks.

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

Comment By: Wincent Colaiuta (wincent)
Date: 2007-03-19 09:40

Message:
> Any other suggestions? I want to come up w/ the right name
> before we add this.

"Facet"?

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-19 08:56

Message:
Agreed that sub_context is the wrong name, and "aspect" WOULD be a great name if it didn't evoke Aspect Oriented Programming.

Any other suggestions? I want to come up w/ the right name before we add this.

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

Comment By: Yurii Rashkovskii (yrashk)
Date: 2007-02-16 07:57

Message:
Also, I think that sub_context isn't good name for aspect. In my understanding 
aspects to be _quite_ orthogonal to context. It's kind of protocol in Smalltalk, or 
something like that.

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

Comment By: Yurii Rashkovskii (yrashk)
Date: 2007-02-16 07:49

Message:
David,

basically your idea about nested blocks with arbitrary names is nice, but I 
foresee one problem. My current implementation supports nested aspects 
and joins their names like "(versioning/backup)" for nested versioning -> 
backup aspects. WDYT?

I will surely be able to rework any of my proof-of-concept implementation of 
rspec extensions as a patch with tests once it will be agreed with rspec 
maintainers.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-02-14 09:02

Message:
Thanks Yurii. This is pretty sweet.

Please take a look at http://rubyforge.org/tracker/index.php?func=detail&aid=8126&group_id=797&atid=3152.

The direction that one is going is that we'd have nested specify blocks that you could invoke using arbitrary names (like "sub_context" or "aspect"). You'd end up being able to do exactly what you propose in your specs, but you'd have to wrap "versioning" in parens to get the output you're looking for:

context "New Document instance" do
  aspect "(versioning)" do
    specify "should have no versions" do
      ...
      
WDYT?

Also, if you're going to submit implementations, please do so in the form of patches here in the this Tracker. Not to suggest that you shouldn't put it on your blog also, but it would be better to have the history of this conversation in one place.

Lastly, regardless of whether we use your suggestion or what I've just described, I'd recommend coming up with another word besides "aspect" to avoid confusion w/ Aspect Oriented Programming.

Cheers,
David


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

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

From noreply at rubyforge.org  Sun Nov 18 21:15:02 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 21:15:02 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-8654 ] Aspects
Message-ID: <20071119021503.0A430185859A@rubyforge.org>

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

Category: runner module
Group: None
>Status: Closed
Priority: 3
Submitted By: Yurii Rashkovskii (yrashk)
Assigned to: Nobody (None)
Summary: Aspects

Initial Comment:
Specifications become a bit messy in large applications. What if implementing aspects for rspec?

context "New Document instance" do

  setup do
    @document = Document.new
  end 

   aspect "versioning" do

    specify "should have no versions" do
     @document.should_have(0).versions
    end

   end

   aspect "printing" do
     aspect "pdf" do
       ...
     end
   end

 end

New Document instance
- (versioning) should have no versions
- (printing/pdf) ...

Initial implementation (requires ActiveSupport, but could be easily ported to pure Ruby) and more details are available at http://rashkovskii.com/articles/2007/2/13/rspec-aspects

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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 02:14

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/35-8654-aspects#ticket-35-2

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-05-11 22:24

Message:
"Facet" is brilliant. Thanks.

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

Comment By: Wincent Colaiuta (wincent)
Date: 2007-03-19 13:40

Message:
> Any other suggestions? I want to come up w/ the right name
> before we add this.

"Facet"?

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-19 12:56

Message:
Agreed that sub_context is the wrong name, and "aspect" WOULD be a great name if it didn't evoke Aspect Oriented Programming.

Any other suggestions? I want to come up w/ the right name before we add this.

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

Comment By: Yurii Rashkovskii (yrashk)
Date: 2007-02-16 12:57

Message:
Also, I think that sub_context isn't good name for aspect. In my understanding 
aspects to be _quite_ orthogonal to context. It's kind of protocol in Smalltalk, or 
something like that.

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

Comment By: Yurii Rashkovskii (yrashk)
Date: 2007-02-16 12:49

Message:
David,

basically your idea about nested blocks with arbitrary names is nice, but I 
foresee one problem. My current implementation supports nested aspects 
and joins their names like "(versioning/backup)" for nested versioning -> 
backup aspects. WDYT?

I will surely be able to rework any of my proof-of-concept implementation of 
rspec extensions as a patch with tests once it will be agreed with rspec 
maintainers.

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

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

Message:
Thanks Yurii. This is pretty sweet.

Please take a look at http://rubyforge.org/tracker/index.php?func=detail&aid=8126&group_id=797&atid=3152.

The direction that one is going is that we'd have nested specify blocks that you could invoke using arbitrary names (like "sub_context" or "aspect"). You'd end up being able to do exactly what you propose in your specs, but you'd have to wrap "versioning" in parens to get the output you're looking for:

context "New Document instance" do
  aspect "(versioning)" do
    specify "should have no versions" do
      ...
      
WDYT?

Also, if you're going to submit implementations, please do so in the form of patches here in the this Tracker. Not to suggest that you shouldn't put it on your blog also, but it would be better to have the history of this conversation in one place.

Lastly, regardless of whether we use your suggestion or what I've just described, I'd recommend coming up with another word besides "aspect" to avoid confusion w/ Aspect Oriented Programming.

Cheers,
David


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

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

From noreply at rubyforge.org  Sun Nov 18 21:22:27 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 21:22:27 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-9278 ] Ajax auto-refresh in
	HTML report
Message-ID: <20071119022227.104251858598@rubyforge.org>

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

Category: reports
Group: None
Status: Open
Priority: 3
Submitted By: Aslak Helles?y (aslak_hellesoy)
Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: Ajax auto-refresh in HTML report

Initial Comment:
We're using RSpec to run a long-running suite (over 300 watir specs).

We're keeping the HTML report open, and we'd like to have it auto-refresh so that we can see the progress without refreshing the browser.

This should be fairly easy to do with Ajax and an IFrame I think....

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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 21:22

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/36-9278-ajax-auto-refresh-in-html-report

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

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

From noreply at rubyforge.org  Sun Nov 18 21:24:05 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 21:24:05 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-9278 ] Ajax auto-refresh in
	HTML report
Message-ID: <20071119022405.54984185859A@rubyforge.org>

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

Category: reports
Group: None
>Status: Closed
Priority: 3
Submitted By: Aslak Helles?y (aslak_hellesoy)
Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: Ajax auto-refresh in HTML report

Initial Comment:
We're using RSpec to run a long-running suite (over 300 watir specs).

We're keeping the HTML report open, and we'd like to have it auto-refresh so that we can see the progress without refreshing the browser.

This should be fairly easy to do with Ajax and an IFrame I think....

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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 02:22

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/36-9278-ajax-auto-refresh-in-html-report

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

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

From noreply at rubyforge.org  Sun Nov 18 21:26:42 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 21:26:42 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-9287 ] Add regular
	expression support to --spec switch
Message-ID: <20071119022642.641EB1858598@rubyforge.org>

Feature Requests item #9287, was opened at 2007-03-14 15:17
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9287&group_id=797

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Chris Hoffman (hoffman_c)
Assigned to: Nobody (None)
Summary: Add regular expression support to --spec switch

Initial Comment:
Hello,
  As a means of getting around the situation described here:

http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9286&group_id=797

I propose adding regular expression support to the --spec switch.  I am not big on typing, and being able to do

spec --spec ".*unique phrase.*" some_spec.rb

instead of

spec --spec "Long specification statement with a unique phrase" some_spec.rb

would be fantastic.

Additionally, you could run all specs related to a loop, by regex'ing out the unique bits of the spec description, a la

spec --spec "should have \d+ items" some_spec.rb

Thanks.  Keep up the good work!

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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 21:26

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/37-9287-add-regular-expression-support-to-spec-switch#ticket-37-2

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

Comment By: Chris Hoffman (hoffman_c)
Date: 2007-05-10 11:58

Message:
Is there any way to have a simple keyword match on these
spec names?

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

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

From noreply at rubyforge.org  Sun Nov 18 21:27:04 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 21:27:04 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-9287 ] Add regular
	expression support to --spec switch
Message-ID: <20071119022704.84CDC185859A@rubyforge.org>

Feature Requests item #9287, was opened at 2007-03-14 19:17
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9287&group_id=797

Category: None
Group: None
>Status: Closed
Priority: 3
Submitted By: Chris Hoffman (hoffman_c)
Assigned to: Nobody (None)
Summary: Add regular expression support to --spec switch

Initial Comment:
Hello,
  As a means of getting around the situation described here:

http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9286&group_id=797

I propose adding regular expression support to the --spec switch.  I am not big on typing, and being able to do

spec --spec ".*unique phrase.*" some_spec.rb

instead of

spec --spec "Long specification statement with a unique phrase" some_spec.rb

would be fantastic.

Additionally, you could run all specs related to a loop, by regex'ing out the unique bits of the spec description, a la

spec --spec "should have \d+ items" some_spec.rb

Thanks.  Keep up the good work!

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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 02:26

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/37-9287-add-regular-expression-support-to-spec-switch#ticket-37-2

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

Comment By: Chris Hoffman (hoffman_c)
Date: 2007-05-10 15:58

Message:
Is there any way to have a simple keyword match on these
spec names?

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

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

From noreply at rubyforge.org  Sun Nov 18 21:27:39 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 21:27:39 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-9304 ] should_all &lt;
	predicate&gt; 
Message-ID: <20071119022739.22378185859C@rubyforge.org>

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

Category: expectation module
Group: None
Status: Open
Priority: 2
Submitted By: Chris Hoffman (hoffman_c)
Assigned to: Nobody (None)
Summary: should_all &lt;predicate&gt;

Initial Comment:
Hello,
  In order to check the properties of each element in a collection, one must presently do the following (as far as I can tell):

mycollection = [2,3,5,7]
mycollection.each { |num| num.should_be_prime }

I suggest an improvement that would significantly increase the readability of these statement types:

mycollection.should_all be_prime

Keep up the good work!  This software has made me into a better programmer.


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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 21:27

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/38-9304-should_all-predicate#ticket-38-2

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-04-04 00:51

Message:
Actually, you're original idea would be more flexible, though I think #should_each would be more ruby-ish:

(1..10).should_each be < 11

While it does look pretty sweet, I'm not 100% sold on the real value of this yet. We've just taken great pains to un-pollute Object so I'm hesitant to add anything else to it.

There are also some questions that come up like whether to add #should_each_not, or whether to fail on the first iteration that fails or collect them all. This could get quite a bit more complicated.

All of that said, you can add this to your spec_helper and get the functionality you're looking for in the mean time.

class Object
  def should_each(*args)
    each {|item| item.should(*args)}
  end
end

Cheers,
David


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

Comment By: Chris Hoffman (hoffman_c)
Date: 2007-03-15 11:14

Message:
Sure, that will work; I'm not intimate with your code base,
so whatever you think is best as far as implementation would
be great.

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

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

Message:
How about:

mycollection.should all_be_prime

Then we don't further pollute Object.

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

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

From noreply at rubyforge.org  Sun Nov 18 21:29:38 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 21:29:38 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-9789 ] Make
	HtmlFormatter#extra_failure_content take the failure as a arg
Message-ID: <20071119022938.CF5BF1858570@rubyforge.org>

Feature Requests item #9789, was opened at 2007-04-03 13:50
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9789&group_id=797

Category: expectation module
Group: None
Status: Open
Priority: 3
Submitted By: Mike Harris (gfunk911)
Assigned to: Nobody (None)
Summary: Make HtmlFormatter#extra_failure_content take the failure as a arg

Initial Comment:
It would be helpful if HtmlFormatter#extra_failure_content could take the failure as an arg, so it could produce content based on the failure.  If the change was made to have rspec only pass the failure if the arity of failure is 1, it would also preserve existing behavior.

I would be happy to code this and submit a patch if that would be helpful.  

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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 21:29

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/39-9789-make-htmlformatter-extra_failure_content-take-the-failure-as-a-arg#ticket-39-2

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

Comment By: Mike Harris (gfunk911)
Date: 2007-04-03 14:21

Message:
I'm running my specs with two formatters attached (specdoc
and html).  I have html content for certain failures that I
only want to display in the html format.  I just
monkeypatched in the changes that I wanted, but I thought it
could be a feature that others would find useful.  

I'll get that patch ready and submit it.  Thanks.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-04-03 14:06

Message:
Please make a patch (no need to ask permission first ;-)

Out of curiosity - what kind of extension are you making that needs this feature?

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

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

From noreply at rubyforge.org  Sun Nov 18 21:29:41 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 21:29:41 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-9304 ] should_all &lt;
	predicate&gt; 
Message-ID: <20071119022941.93D5C18585DE@rubyforge.org>

Feature Requests item #9304, was opened at 2007-03-15 14:58
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9304&group_id=797

Category: expectation module
Group: None
>Status: Closed
Priority: 2
Submitted By: Chris Hoffman (hoffman_c)
Assigned to: Nobody (None)
Summary: should_all &lt;predicate&gt;

Initial Comment:
Hello,
  In order to check the properties of each element in a collection, one must presently do the following (as far as I can tell):

mycollection = [2,3,5,7]
mycollection.each { |num| num.should_be_prime }

I suggest an improvement that would significantly increase the readability of these statement types:

mycollection.should_all be_prime

Keep up the good work!  This software has made me into a better programmer.


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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 02:27

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/38-9304-should_all-predicate#ticket-38-2

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-04-04 04:51

Message:
Actually, you're original idea would be more flexible, though I think #should_each would be more ruby-ish:

(1..10).should_each be < 11

While it does look pretty sweet, I'm not 100% sold on the real value of this yet. We've just taken great pains to un-pollute Object so I'm hesitant to add anything else to it.

There are also some questions that come up like whether to add #should_each_not, or whether to fail on the first iteration that fails or collect them all. This could get quite a bit more complicated.

All of that said, you can add this to your spec_helper and get the functionality you're looking for in the mean time.

class Object
  def should_each(*args)
    each {|item| item.should(*args)}
  end
end

Cheers,
David


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

Comment By: Chris Hoffman (hoffman_c)
Date: 2007-03-15 15:14

Message:
Sure, that will work; I'm not intimate with your code base,
so whatever you think is best as far as implementation would
be great.

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

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

Message:
How about:

mycollection.should all_be_prime

Then we don't further pollute Object.

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

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

From noreply at rubyforge.org  Sun Nov 18 21:30:33 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 21:30:33 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-10285 ] DSL for example
	execution and non-procedural expectation/state testing
Message-ID: <20071119023033.13E3B1858595@rubyforge.org>

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

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Simon Nicholls (simon_nicholls)
Assigned to: Nobody (None)
Summary: DSL for example execution and non-procedural expectation/state testing

Initial Comment:
Currently, taking Rails controller testing as an example, this would work for DRY state based testing:

describe SomeController do
  before do
    #mocks and stubs allowing @test to be tested
    get 'test_action'
  end
 
  it "should have good state" do
    @test.should == ""
  end

  #...other state specs
end

But you can't set mock expectations, as the production code execution is in the setup. This is better for expectation style:

describe SomeController do
  before do
    #mocks and stubs, allowing @test to have expectations set
  end

  after do
    get 'test_action'
  end

  it "should call test" do
    @test.should_receive(:test) #etc
  end

  #...other mock expectations
end

Having execution after the specs allows for mock expectations, but then state specs will be jumping the gun.

On top of creating problems if trying to mock and state test together, it doesn't feel right that the actual production code example run has no clear home of it's own.

What I'd like is an optional way to forget ordering of mock expectations and state checking - they are all specs which should be written before running the SUT - and have the execution wrapped in some nice DSL (This would also create a context for further features)

describe SomeController do
  before do
    #mocks and stubs, allowing @test use in specs
  end

  example do
    get 'test_action'
  end

  it "should call test" do
    @test.should_receive(:test) #etc
  end

  it "should have good state" do
    @test.should == ""
  end

end

If "should" and "should_not" state expectations could defer until after the example is run, when mocks are verified, then all would be peachy. DRY specs, and a clear separation of concerns. It seems non-trivial but perhaps possible.

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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 21:30

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/40-10285-dsl-for-example-execution-and-non-procedural-expectation-state-testing#ticket-40-2

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

Comment By: Simon Nicholls (simon_nicholls)
Date: 2007-04-22 12:11

Message:
Yeah, I'm kind of jumping into the deep end here. Just
wanted to throw something out and see what you thought.

I'd be pretty happy with something along the lines of the
2nd version actually, as it does capture the spirit of the spec.

I have some niggly thoughts in my mind about being able to
state a default before/after event to run if not overridden
(using new dsl or hanging off some existing dsl), but I
can't really say if it's needed.

Dude, it's Sunday! Thanks for getting back so quickly! :D

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-04-22 09:49

Message:
As Aslak and Dave and I have all stated emphatically, clarity is king in examples in our view, which means a little moisture is OK if it results in better feedback from reading the examples. I think doing this implicitly would be nothing but confusing to anyone reading the specs trying to understand a failure. When did what run?

There was a similar suggestion to this either in the tracker or on one of the mailing lists that read more like this:

describe SomeController do
  def event
    get 'test_action'
  end

  it "should call test", before_event do
    @test.should_receive(:test) #etc
  end

  it "should have good state", after_event do
    @test.should == ""
  end

end

I'd be more open to something like that which is more explicit. Actually, how about "during_event" for the mock expectation - then you could have this:

  it "should call test", during_event do
    @test.should_receive(:test) #etc
  end

  it "should have good state", after_event do
    @test.should == ""
  end

Now THAT reads really nicely. WDYT?


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

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

From noreply at rubyforge.org  Sun Nov 18 21:31:14 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 21:31:14 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-9789 ] Make
	HtmlFormatter#extra_failure_content take the failure as a arg
Message-ID: <20071119023115.0976D185859A@rubyforge.org>

Feature Requests item #9789, was opened at 2007-04-03 17:50
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9789&group_id=797

Category: expectation module
Group: None
>Status: Closed
Priority: 3
Submitted By: Mike Harris (gfunk911)
Assigned to: Nobody (None)
Summary: Make HtmlFormatter#extra_failure_content take the failure as a arg

Initial Comment:
It would be helpful if HtmlFormatter#extra_failure_content could take the failure as an arg, so it could produce content based on the failure.  If the change was made to have rspec only pass the failure if the arity of failure is 1, it would also preserve existing behavior.

I would be happy to code this and submit a patch if that would be helpful.  

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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 02:29

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/39-9789-make-htmlformatter-extra_failure_content-take-the-failure-as-a-arg#ticket-39-2

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

Comment By: Mike Harris (gfunk911)
Date: 2007-04-03 18:21

Message:
I'm running my specs with two formatters attached (specdoc
and html).  I have html content for certain failures that I
only want to display in the html format.  I just
monkeypatched in the changes that I wanted, but I thought it
could be a feature that others would find useful.  

I'll get that patch ready and submit it.  Thanks.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-04-03 18:06

Message:
Please make a patch (no need to ask permission first ;-)

Out of curiosity - what kind of extension are you making that needs this feature?

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

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

From noreply at rubyforge.org  Sun Nov 18 21:31:29 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 21:31:29 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-10285 ] DSL for example
	execution and non-procedural expectation/state testing
Message-ID: <20071119023129.5C332185859A@rubyforge.org>

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

Category: None
Group: None
>Status: Closed
Priority: 3
Submitted By: Simon Nicholls (simon_nicholls)
Assigned to: Nobody (None)
Summary: DSL for example execution and non-procedural expectation/state testing

Initial Comment:
Currently, taking Rails controller testing as an example, this would work for DRY state based testing:

describe SomeController do
  before do
    #mocks and stubs allowing @test to be tested
    get 'test_action'
  end
 
  it "should have good state" do
    @test.should == ""
  end

  #...other state specs
end

But you can't set mock expectations, as the production code execution is in the setup. This is better for expectation style:

describe SomeController do
  before do
    #mocks and stubs, allowing @test to have expectations set
  end

  after do
    get 'test_action'
  end

  it "should call test" do
    @test.should_receive(:test) #etc
  end

  #...other mock expectations
end

Having execution after the specs allows for mock expectations, but then state specs will be jumping the gun.

On top of creating problems if trying to mock and state test together, it doesn't feel right that the actual production code example run has no clear home of it's own.

What I'd like is an optional way to forget ordering of mock expectations and state checking - they are all specs which should be written before running the SUT - and have the execution wrapped in some nice DSL (This would also create a context for further features)

describe SomeController do
  before do
    #mocks and stubs, allowing @test use in specs
  end

  example do
    get 'test_action'
  end

  it "should call test" do
    @test.should_receive(:test) #etc
  end

  it "should have good state" do
    @test.should == ""
  end

end

If "should" and "should_not" state expectations could defer until after the example is run, when mocks are verified, then all would be peachy. DRY specs, and a clear separation of concerns. It seems non-trivial but perhaps possible.

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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 02:30

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/40-10285-dsl-for-example-execution-and-non-procedural-expectation-state-testing#ticket-40-2

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

Comment By: Simon Nicholls (simon_nicholls)
Date: 2007-04-22 16:11

Message:
Yeah, I'm kind of jumping into the deep end here. Just
wanted to throw something out and see what you thought.

I'd be pretty happy with something along the lines of the
2nd version actually, as it does capture the spirit of the spec.

I have some niggly thoughts in my mind about being able to
state a default before/after event to run if not overridden
(using new dsl or hanging off some existing dsl), but I
can't really say if it's needed.

Dude, it's Sunday! Thanks for getting back so quickly! :D

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-04-22 13:49

Message:
As Aslak and Dave and I have all stated emphatically, clarity is king in examples in our view, which means a little moisture is OK if it results in better feedback from reading the examples. I think doing this implicitly would be nothing but confusing to anyone reading the specs trying to understand a failure. When did what run?

There was a similar suggestion to this either in the tracker or on one of the mailing lists that read more like this:

describe SomeController do
  def event
    get 'test_action'
  end

  it "should call test", before_event do
    @test.should_receive(:test) #etc
  end

  it "should have good state", after_event do
    @test.should == ""
  end

end

I'd be more open to something like that which is more explicit. Actually, how about "during_event" for the mock expectation - then you could have this:

  it "should call test", during_event do
    @test.should_receive(:test) #etc
  end

  it "should have good state", after_event do
    @test.should == ""
  end

Now THAT reads really nicely. WDYT?


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

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

From noreply at rubyforge.org  Sun Nov 18 21:31:40 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 21:31:40 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-10539 ] Add class_type
	constraint for mocks
Message-ID: <20071119023140.642C418585A3@rubyforge.org>

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

Category: mock module
Group: None
Status: Open
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: Add class_type constraint for mocks

Initial Comment:
I know that we are all supposed to think Duck Typing :), but sometimes its more convenient and useful to have a constraint on a Class type.

Maybe we can add a class_type method to be used in addition to the duck_type method.



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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 21:31

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/42-10539-add-class_type-constraint-for-mocks#ticket-42-2

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-05-03 15:00

Message:
No. It's for matching expressions. The mock thing is the sneaky part :)

It's intent is more for expectations like:

File.should exist(path)



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

Comment By: Brian Takita (btakita)
Date: 2007-05-03 14:57

Message:
That works. So predicate_matchers is a spec/mock only thing
right?

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-05-03 00:23

Message:
You can kinda fake this now - it's sneaky, but....

describe "sneaky use of predicate matchers as mock argument matcher" do
  predicate_matchers[:a] = :is_a?
  
  it "should make Brian happy" do
    m = mock("thing")
    m.should_receive(:message).with(a(String))
    m.message("this is a string")
  end
end

WDYT?



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

Comment By: Brian Takita (btakita)
Date: 2007-05-02 23:51

Message:
Sorry, here is an example.

it "sets Expectations differ when differ_class is set" do
  @options.differ_class = Spec::Expectations::Differs::Default
 
Spec::Expectations.should_receive(:differ=).with(:anything).and_return
do |arg|
    arg.class.should == Spec::Expectations::Differs::Default
  end
  @options.create_behaviour_runner
end

It would be nice to say:
Spec::Expectations.should_receive(:differ=).with(class_type(Spec::Expectations::Differs::Default))

Saying duck_type would be ambigious in this situation.

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

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

Message:
Would this do what you are looking for?

http://rubyforge.org/tracker/index.php?func=detail&aid=5064&group_id=797&atid=3152

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

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

From noreply at rubyforge.org  Sun Nov 18 21:32:36 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 21:32:36 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-15373 ] Rspec In Spanish
Message-ID: <20071119023236.4866318585B2@rubyforge.org>

Feature Requests item #15373, was opened at 2007-11-05 19: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: Chad Humphries (spicycode)
Date: 2007-11-18 21:32

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/43-15373-rspec-in-spanish#ticket-43-2

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

Comment By: raimond garcia (voodoorai2000)
Date: 2007-11-06 08: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-05 19: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  Sun Nov 18 21:34:44 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 21:34:44 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-15394 ] RSpec website does
	not render correctly with IE6
Message-ID: <20071119023444.770FB185859C@rubyforge.org>

Feature Requests item #15394, was opened at 2007-11-06 11: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.)


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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 21:34

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/44-15394-rspec-website-does-not-render-correctly-with-ie6

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

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

From noreply at rubyforge.org  Sun Nov 18 21:35:10 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 21:35:10 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-15718 ] warn user when two
	examples with the same name appear in the same example group
Message-ID: <20071119023511.1025E18585A3@rubyforge.org>

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

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Nobody (None)
Summary: warn user when two examples with the same name appear in the same example group

Initial Comment:
Right now if you do this:

describe Foo do
  it "should bar" do
    ...
  end

  it "should bar" do
    ...
  end
end

RSpec will run both examples and provide output like this:

Foo
- should bar
- should bar

Perhaps rspec should warn you or raise an error when you do this.


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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 21:35

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/45-15718-warn-user-when-two-examples-with-the-same-name-appear-in-the-same-example-group

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

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

From noreply at rubyforge.org  Sun Nov 18 21:45:19 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 21:45:19 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-11428 ] autotest with --drb and --color
Message-ID: <20071119024519.884C918585A3@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: autotest with --drb and --color

Initial Comment:
No color is seen when using autotest with an options file that contains both --drb and --color

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

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 21:45

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/46-11428-autotest-with-drb-and-color#ticket-46-2

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

Comment By: Richard Poirier (richpoirier)
Date: 2007-08-20 16:39

Message:
I have the same problem running "ruby script/spec spec/ --drb --colour"

I'm running:
Vista 32-bit
ruby 1.8.6
rails 1.2.3
win32console 1.0.8
rspec 1.0.8

I found a workaround, but don't really understand why it works. Maybe it can help someone really fix the bug though.

I add "require 'Win32/Console/ANSI'" before the last line in my spec
file and change the STDOUT parameter in the last line to $stdout.

So my <project>/script/spec looks like this:

#!/usr/bin/env ruby
$LOAD_PATH.unshift(File.expand_path(File.dirname(__FILE__) + "/../
vendor/plugins/rspec/lib"))
require 'spec'
require 'Win32/Console/ANSI'
::Spec::Runner::CommandLine.run(ARGV, STDERR, $stdout, true, true)

It's not perfect. The first run will print the output to the console
that spec_server is running in. All subsequent runs will print to the
correct console though. I couldn't figure out why it was doing this
but the way it works is good enough for me until the bug is really fixed.

----------------------------------------------------------------------

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-06-09 20:54

Message:
OS X.4.9
Ruby 1.8.6
rspec trunk (@ rev. 2087)
rspec_on_rails trunk
autotest 3.6.0

This bug has been around since Nick Seiger's original
plugin.  David C. and I have talked about it before on the
mailing list.  

I would have written a spec, but I got intimidated by the
idea of mocking DRB, Autotest, and color values given by the
terminal.


Sorry that you had to drop in that boilerplate message.  I'm
sorry that it's even a boiler plate message.

----------------------------------------------------------------------

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-06-08 06:55

Message:
OS X.4.9
Ruby 1.8.6
rspec trunk (@ rev. 2087)
rspec_on_rails trunk
autotest 3.6.0

This bug has been around since Nick Seiger's original
plugin.  David C. and I have talked about it before on the
mailing list.  

I would have written a spec, but I got intimidated by the
idea of mocking DRB, Autotest, and color values given by the
terminal.


Sorry that you had to drop in that boilerplate message.  I'm
sorry that it's even a boiler plate message.

----------------------------------------------------------------------

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-06-08 05:14

Message:
Before investigating this we need to know the versions of all 
relevant software you are using, for example:

* OS X 10.4.9
* Ruby 1.8.6
* RSpec 1.8.2 or RSpec trunk r1643
* Spec::Rails 1.8.2 or Spec::Rails tag r1234...
* Rails 1.2.3 or Rails edge r5645
* Whatever other relevant software.

Without this information it's like solving 1 equation (your 
question) with 5 unknown variables (the versions).

We strongly recommend that you use the latest released version of
RSpec, alternatively the subversion trunk (if you're the bleeding
edge kind of person).

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11428&group_id=797

From noreply at rubyforge.org  Sun Nov 18 21:46:41 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 21:46:41 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-11488 ] rspec-1.0.5.tgz is broken
Message-ID: <20071119024641.309D318585B2@rubyforge.org>

Bugs item #11488, was opened at 2007-06-10 09:52
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11488&group_id=797

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: rspec-1.0.5.tgz is broken

Initial Comment:
>From email on the rspec-devel list:

I noticed that rspec-1.0.5.tgz is broken:

$ wget -O http://rubyforge.org/frs/download.php/21457/rspec-1.0.5.tgz
...
12:24:11 (7.21 KB/s) - `rspec-1.0.5.tgz' saved [115639/115639]

$ md5sum rspec-1.0.5.tgz
1851730ca994cc31fd865f8894a2510e  rspec-1.0.5.tgz

$ tar xzf rspec-1.0.5.tgz
gzip: stdin: decompression OK, trailing garbage ignored
tar: Child returned status 2
tar: Error exit delayed from previous errors

Please provide a gzipped tarball that unpacks cleanly.
The same problem exists with older tgz's, btw.

Thanks,
Tilman


----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 21:46

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/47-11488-rspec-1-0-5-tgz-is-broken#ticket-47-2

----------------------------------------------------------------------

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-06-11 16:52

Message:
It looks like all the .tgz files are broken:

rspec-1.0.5.tgz
RSpec-1.0.5.tmbundle.tgz
rspec_on_rails-1.0.5.tgz

The other files are fine, even the bigger rspec-1.0.5.zip. I therefore don't hink it has to do with size.

Something isn't handling the tgz *type* properly. It could be the MetaProject upload logic or something at Rubyforge. Rake seems to build things ok locally.

Maybe we changing it to tar.gz and/or using the "Source.gz" RubyForge type will change things?

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-06-10 10:22

Message:
I get the same problem with the tgz's up on rubyforge, but when I create them locally they unpack fine. Not sure where things are getting corrupted yet, but looking into it. If anybody has similar experience (i.e. packing/unpacking locally is fine but problems occur once uploaded and downloaded), please advise.

Thanks,
David

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11488&group_id=797

From noreply at rubyforge.org  Sun Nov 18 21:49:23 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 21:49:23 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-10539 ] Add class_type
	constraint for mocks
Message-ID: <20071119024923.8644118585A3@rubyforge.org>

Feature Requests item #10539, was opened at 2007-05-03 02:30
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10539&group_id=797

Category: mock module
Group: None
>Status: Closed
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: Add class_type constraint for mocks

Initial Comment:
I know that we are all supposed to think Duck Typing :), but sometimes its more convenient and useful to have a constraint on a Class type.

Maybe we can add a class_type method to be used in addition to the duck_type method.



----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 02:31

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/42-10539-add-class_type-constraint-for-mocks#ticket-42-2

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-05-03 19:00

Message:
No. It's for matching expressions. The mock thing is the sneaky part :)

It's intent is more for expectations like:

File.should exist(path)



----------------------------------------------------------------------

Comment By: Brian Takita (btakita)
Date: 2007-05-03 18:57

Message:
That works. So predicate_matchers is a spec/mock only thing
right?

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-05-03 04:23

Message:
You can kinda fake this now - it's sneaky, but....

describe "sneaky use of predicate matchers as mock argument matcher" do
  predicate_matchers[:a] = :is_a?
  
  it "should make Brian happy" do
    m = mock("thing")
    m.should_receive(:message).with(a(String))
    m.message("this is a string")
  end
end

WDYT?



----------------------------------------------------------------------

Comment By: Brian Takita (btakita)
Date: 2007-05-03 03:51

Message:
Sorry, here is an example.

it "sets Expectations differ when differ_class is set" do
  @options.differ_class = Spec::Expectations::Differs::Default
 
Spec::Expectations.should_receive(:differ=).with(:anything).and_return
do |arg|
    arg.class.should == Spec::Expectations::Differs::Default
  end
  @options.create_behaviour_runner
end

It would be nice to say:
Spec::Expectations.should_receive(:differ=).with(class_type(Spec::Expectations::Differs::Default))

Saying duck_type would be ambigious in this situation.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-05-03 03:16

Message:
Would this do what you are looking for?

http://rubyforge.org/tracker/index.php?func=detail&aid=5064&group_id=797&atid=3152

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10539&group_id=797

From noreply at rubyforge.org  Sun Nov 18 21:49:42 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 21:49:42 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-15373 ] Rspec In Spanish
Message-ID: <20071119024942.69DF118585B2@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: Closed
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: Chad Humphries (spicycode)
Date: 2007-11-19 02:32

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/43-15373-rspec-in-spanish#ticket-43-2

----------------------------------------------------------------------

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 noreply at rubyforge.org  Sun Nov 18 21:50:01 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 21:50:01 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-15394 ] RSpec website does
	not render correctly with IE6
Message-ID: <20071119025001.5641E18585B7@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: Closed
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.)


----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 02:34

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/44-15394-rspec-website-does-not-render-correctly-with-ie6

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=15394&group_id=797

From noreply at rubyforge.org  Sun Nov 18 21:50:08 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 21:50:08 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-11526 ] rspec fails to dynamically bind
	DelegateClass methods
Message-ID: <20071119025008.E3A3618585B7@rubyforge.org>

Bugs item #11526, was opened at 2007-06-12 11:55
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11526&group_id=797

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: John Prince (jtprince)
Assigned to: Nobody (None)
Summary: rspec fails to dynamically bind DelegateClass methods

Initial Comment:
DelegateClass fails with rspec when methods are defined in the the delegating class.  I'm using a delegate class right now and I'm having to write spaghetti code to get things to work properly.  Here's code that demonstrates the problem:

---
require 'delegate'
gem 'rspec'
# Version 1.0.5

############################################################
# CONTROL EXAMPLE: Works FINE.
############################################################
class InheritedClass < Array
 def large?
   self.size >= 5
 end
end

describe InheritedClass, "normal inheriting class is OK" do
 it 'works just fine' do
   myclass = InheritedClass.new([1,2,3,4,5,6])
   myclass.should be_large
 end
end


############################################################
# rspec should work on DelegateClasses.  Not sure how...
############################################################

class DelegateKlass < DelegateClass(Array)

 def initialize(array)
   @internal_array = array
   super(@internal_array)
 end

 def large?
   @internal_array.size >= 5
 end

end

=begin
# will work if this code is available.
class Array
 def large?
   self.size >= 5
 end
end
=end


describe DelegateKlass, "delegate class fails" do
 it 'does not work on methods defined within the delegating class' do
   myclass = DelegateKlass.new([1,2,3,4,5,6])
   myclass.should be_large
 end
end

---

#############################################
# OUTPUT:
#############################################

.F

1)
NoMethodError in 'DelegateKlass delegate class fails does not work on 
delegate class'
undefined method `large?' for [1, 2, 3, 4, 5, 6]:Array
./spec_delegate.rb:53:

Finished in 0.007365 seconds

2 examples, 1 failure

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 21:50

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/48-11526-rspec-fails-to-dynamically-bind-delegateclass-methods#ticket-48-2

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-09-07 06:05

Message:
Well, I've learned one interesting thing about this. If you define the DelegateKlass first and then require 'spec' (or gem 'rspec') it works fine. So there is some odd relationship between what require 'spec' does to Object or the main object and what DelegateClass does.

Don't know more than that yet.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11526&group_id=797

From noreply at rubyforge.org  Sun Nov 18 21:50:21 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 21:50:21 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-15718 ] warn user when two
	examples with the same name appear in the same example group
Message-ID: <20071119025021.B0D2F18585B2@rubyforge.org>

Feature Requests item #15718, was opened at 2007-11-18 17:20
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=15718&group_id=797

Category: None
Group: None
>Status: Closed
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Nobody (None)
Summary: warn user when two examples with the same name appear in the same example group

Initial Comment:
Right now if you do this:

describe Foo do
  it "should bar" do
    ...
  end

  it "should bar" do
    ...
  end
end

RSpec will run both examples and provide output like this:

Foo
- should bar
- should bar

Perhaps rspec should warn you or raise an error when you do this.


----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 02:35

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/45-15718-warn-user-when-two-examples-with-the-same-name-appear-in-the-same-example-group

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=15718&group_id=797

From noreply at rubyforge.org  Sun Nov 18 21:50:39 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 21:50:39 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-11428 ] autotest with --drb and --color
Message-ID: <20071119025039.D6FC718585A3@rubyforge.org>

Bugs item #11428, was opened at 2007-06-08 06:46
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11428&group_id=797

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: autotest with --drb and --color

Initial Comment:
No color is seen when using autotest with an options file that contains both --drb and --color

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 02:45

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/46-11428-autotest-with-drb-and-color#ticket-46-2

----------------------------------------------------------------------

Comment By: Richard Poirier (richpoirier)
Date: 2007-08-20 20:39

Message:
I have the same problem running "ruby script/spec spec/ --drb --colour"

I'm running:
Vista 32-bit
ruby 1.8.6
rails 1.2.3
win32console 1.0.8
rspec 1.0.8

I found a workaround, but don't really understand why it works. Maybe it can help someone really fix the bug though.

I add "require 'Win32/Console/ANSI'" before the last line in my spec
file and change the STDOUT parameter in the last line to $stdout.

So my <project>/script/spec looks like this:

#!/usr/bin/env ruby
$LOAD_PATH.unshift(File.expand_path(File.dirname(__FILE__) + "/../
vendor/plugins/rspec/lib"))
require 'spec'
require 'Win32/Console/ANSI'
::Spec::Runner::CommandLine.run(ARGV, STDERR, $stdout, true, true)

It's not perfect. The first run will print the output to the console
that spec_server is running in. All subsequent runs will print to the
correct console though. I couldn't figure out why it was doing this
but the way it works is good enough for me until the bug is really fixed.

----------------------------------------------------------------------

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-06-10 00:54

Message:
OS X.4.9
Ruby 1.8.6
rspec trunk (@ rev. 2087)
rspec_on_rails trunk
autotest 3.6.0

This bug has been around since Nick Seiger's original
plugin.  David C. and I have talked about it before on the
mailing list.  

I would have written a spec, but I got intimidated by the
idea of mocking DRB, Autotest, and color values given by the
terminal.


Sorry that you had to drop in that boilerplate message.  I'm
sorry that it's even a boiler plate message.

----------------------------------------------------------------------

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-06-08 10:55

Message:
OS X.4.9
Ruby 1.8.6
rspec trunk (@ rev. 2087)
rspec_on_rails trunk
autotest 3.6.0

This bug has been around since Nick Seiger's original
plugin.  David C. and I have talked about it before on the
mailing list.  

I would have written a spec, but I got intimidated by the
idea of mocking DRB, Autotest, and color values given by the
terminal.


Sorry that you had to drop in that boilerplate message.  I'm
sorry that it's even a boiler plate message.

----------------------------------------------------------------------

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-06-08 09:14

Message:
Before investigating this we need to know the versions of all 
relevant software you are using, for example:

* OS X 10.4.9
* Ruby 1.8.6
* RSpec 1.8.2 or RSpec trunk r1643
* Spec::Rails 1.8.2 or Spec::Rails tag r1234...
* Rails 1.2.3 or Rails edge r5645
* Whatever other relevant software.

Without this information it's like solving 1 equation (your 
question) with 5 unknown variables (the versions).

We strongly recommend that you use the latest released version of
RSpec, alternatively the subversion trunk (if you're the bleeding
edge kind of person).

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11428&group_id=797

From noreply at rubyforge.org  Sun Nov 18 21:50:55 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 21:50:55 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-11488 ] rspec-1.0.5.tgz is broken
Message-ID: <20071119025055.2CD8F18585A3@rubyforge.org>

Bugs item #11488, was opened at 2007-06-10 13:52
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11488&group_id=797

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: rspec-1.0.5.tgz is broken

Initial Comment:
>From email on the rspec-devel list:

I noticed that rspec-1.0.5.tgz is broken:

$ wget -O http://rubyforge.org/frs/download.php/21457/rspec-1.0.5.tgz
...
12:24:11 (7.21 KB/s) - `rspec-1.0.5.tgz' saved [115639/115639]

$ md5sum rspec-1.0.5.tgz
1851730ca994cc31fd865f8894a2510e  rspec-1.0.5.tgz

$ tar xzf rspec-1.0.5.tgz
gzip: stdin: decompression OK, trailing garbage ignored
tar: Child returned status 2
tar: Error exit delayed from previous errors

Please provide a gzipped tarball that unpacks cleanly.
The same problem exists with older tgz's, btw.

Thanks,
Tilman


----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 02:46

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/47-11488-rspec-1-0-5-tgz-is-broken#ticket-47-2

----------------------------------------------------------------------

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-06-11 20:52

Message:
It looks like all the .tgz files are broken:

rspec-1.0.5.tgz
RSpec-1.0.5.tmbundle.tgz
rspec_on_rails-1.0.5.tgz

The other files are fine, even the bigger rspec-1.0.5.zip. I therefore don't hink it has to do with size.

Something isn't handling the tgz *type* properly. It could be the MetaProject upload logic or something at Rubyforge. Rake seems to build things ok locally.

Maybe we changing it to tar.gz and/or using the "Source.gz" RubyForge type will change things?

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-06-10 14:22

Message:
I get the same problem with the tgz's up on rubyforge, but when I create them locally they unpack fine. Not sure where things are getting corrupted yet, but looking into it. If anybody has similar experience (i.e. packing/unpacking locally is fine but problems occur once uploaded and downloaded), please advise.

Thanks,
David

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11488&group_id=797

From noreply at rubyforge.org  Sun Nov 18 21:51:23 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 21:51:23 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-11526 ] rspec fails to dynamically bind
	DelegateClass methods
Message-ID: <20071119025123.D958218585B2@rubyforge.org>

Bugs item #11526, was opened at 2007-06-12 15:55
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11526&group_id=797

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: John Prince (jtprince)
Assigned to: Nobody (None)
Summary: rspec fails to dynamically bind DelegateClass methods

Initial Comment:
DelegateClass fails with rspec when methods are defined in the the delegating class.  I'm using a delegate class right now and I'm having to write spaghetti code to get things to work properly.  Here's code that demonstrates the problem:

---
require 'delegate'
gem 'rspec'
# Version 1.0.5

############################################################
# CONTROL EXAMPLE: Works FINE.
############################################################
class InheritedClass < Array
 def large?
   self.size >= 5
 end
end

describe InheritedClass, "normal inheriting class is OK" do
 it 'works just fine' do
   myclass = InheritedClass.new([1,2,3,4,5,6])
   myclass.should be_large
 end
end


############################################################
# rspec should work on DelegateClasses.  Not sure how...
############################################################

class DelegateKlass < DelegateClass(Array)

 def initialize(array)
   @internal_array = array
   super(@internal_array)
 end

 def large?
   @internal_array.size >= 5
 end

end

=begin
# will work if this code is available.
class Array
 def large?
   self.size >= 5
 end
end
=end


describe DelegateKlass, "delegate class fails" do
 it 'does not work on methods defined within the delegating class' do
   myclass = DelegateKlass.new([1,2,3,4,5,6])
   myclass.should be_large
 end
end

---

#############################################
# OUTPUT:
#############################################

.F

1)
NoMethodError in 'DelegateKlass delegate class fails does not work on 
delegate class'
undefined method `large?' for [1, 2, 3, 4, 5, 6]:Array
./spec_delegate.rb:53:

Finished in 0.007365 seconds

2 examples, 1 failure

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 02:50

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/48-11526-rspec-fails-to-dynamically-bind-delegateclass-methods#ticket-48-2

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-09-07 10:05

Message:
Well, I've learned one interesting thing about this. If you define the DelegateKlass first and then require 'spec' (or gem 'rspec') it works fine. So there is some odd relationship between what require 'spec' does to Object or the main object and what DelegateClass does.

Don't know more than that yet.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11526&group_id=797

From noreply at rubyforge.org  Sun Nov 18 22:18:09 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 22:18:09 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-11536 ] controller.should
	render_template must be defined after the action
Message-ID: <20071119031809.E14581858598@rubyforge.org>

Bugs item #11536, was opened at 2007-06-12 18:25
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11536&group_id=797

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: courtenay 3 (court3nay)
Assigned to: Nobody (None)
Summary: controller.should render_template must be defined after the action

Initial Comment:
this fails:

  it "should render index.rhtml" do
    response.should render_template(:index)
    do_get
  end

this works:

  it "should render index.rhtml" do
    do_get
    response.should render_template(:index)
  end

Here's my patch; it doesn't "feel" right to me, since there's no other error handling in that file.

Index: lib/spec/rails/matchers/render_template.rb
===================================================================
--- lib/spec/rails/matchers/render_template.rb  (revision 1429)
+++ lib/spec/rails/matchers/render_template.rb  (working copy)
@@ -9,6 +9,9 @@
         end
       
         def matches?(response)
+          unless response.respond_to?:rendered_file
+            raise "The response has not yet rendered or is not a Response object. This matcher (render_template) must be defined after the controller action is called."
+          end
           @actual = response.rendered_file(!expected.include?('/'))
           actual == expected
         end


----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 22:18

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/49-11536-controller-should-render_template-must-be-defined-after-the-action#ticket-49-2

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-09-12 03:22

Message:
It's a bit too late for that Bryan. We're committed to not changing these. We could alias it, but I'd prefer to avoid going down that path. I think we need to figure out a way to give the right feedback when it's used incorrectly.

----------------------------------------------------------------------

Comment By: Bryan Helmkamp (brynary)
Date: 2007-09-12 03:14

Message:
Perhaps the matcher should be renamed from render_file to have_rendered_file. Thoughts?

If this sounds good, I'll write a patch.

----------------------------------------------------------------------

Comment By: courtenay 3 (court3nay)
Date: 2007-06-12 18:34

Message:
the patch doesn't actually work like I intended, but I can't see a way of checking 
that the order is correct

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11536&group_id=797

From noreply at rubyforge.org  Sun Nov 18 22:18:40 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 22:18:40 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-11562 ] Rake RCov task should work out
	of the box with --drb in spec.opts
Message-ID: <20071119031840.73B361858598@rubyforge.org>

Bugs item #11562, was opened at 2007-06-13 19:26
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11562&group_id=797

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: Rake RCov task should work out of the box with --drb in spec.opts

Initial Comment:

The rake task spec:rcov does not work if --drb is specified in spec.opts (in a rails project).  Here is the output:

euclid% rake spec:rcov
(in /Users/smtlaissezfaire/Sites/rails/changelog)
................................*..*..*...................*............. 
...................................

Finished in 5.751487 seconds

107 examples, 0 failures, 4 not implemented

No file to analyze was found. All the files loaded by rcov matched  
one of the
following expressions, and were thus ignored:
[/\A\/opt\/local\/lib/,
/\btc_[^.]*.rb/,
/_test\.rb\z/,
/\btest\//,
/\bvendor\//,
/\A\/opt\/local\/lib\/ruby\/gems\/1\.8\/gems\/rcov\-0\.8\.0\.2\/lib\/ 
rcov\/report\.rb\z/,
/spec/,
/\bvendor\//,
/\bconfig\//,
/\benvironment\//]

You can solve this by doing one or more of the following:
* rename the files not to be ignored so they don't match the above  
regexps
* use --include-file to give a list of patterns for files not to be  
ignored
* use --exclude-only to give the new list of regexps to match against
* structure your code as follows:
       test/test_*.rb  for the test cases
       lib/**/*.rb     for the target source code whose coverage you  
want
   making sure that the test/test_*.rb files are loading from lib/,  
e.g. by
   using the -Ilib command-line argument, adding
     $:.unshift File.join(File.dirname(__FILE__), "..", "lib")
   to test/test_*.rb, or running rcov via a Rakefile (read the RDoc
   documentation or README.rake in the source distribution).



But without --drb in spec.opts it works just fine.  Here is my setup:

Mac OS X.4.9

Fetching external item into 'vendor/rails'
External at revision 7014.

Fetching external item into 'vendor/plugins/rspec'
External at revision 2098.

Fetching external item into 'vendor/plugins/rspec_on_rails'
External at revision 2098.

Fetching external item into 'vendor/plugins/rails_rcov'
External at revision 12.

rcov gem @version 0.8.0.2


If you have some tips on how to write a spec for this, I'd be glad to write a patch.





----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 22:18

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/50-11562-rake-rcov-task-should-work-out-of-the-box-with-drb-in-spec-opts

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11562&group_id=797

From noreply at rubyforge.org  Sun Nov 18 22:19:17 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 22:19:17 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-11536 ] controller.should
	render_template must be defined after the action
Message-ID: <20071119031917.A80C71858598@rubyforge.org>

Bugs item #11536, was opened at 2007-06-12 22:25
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11536&group_id=797

Category: rails plugin
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: courtenay 3 (court3nay)
Assigned to: Nobody (None)
Summary: controller.should render_template must be defined after the action

Initial Comment:
this fails:

  it "should render index.rhtml" do
    response.should render_template(:index)
    do_get
  end

this works:

  it "should render index.rhtml" do
    do_get
    response.should render_template(:index)
  end

Here's my patch; it doesn't "feel" right to me, since there's no other error handling in that file.

Index: lib/spec/rails/matchers/render_template.rb
===================================================================
--- lib/spec/rails/matchers/render_template.rb  (revision 1429)
+++ lib/spec/rails/matchers/render_template.rb  (working copy)
@@ -9,6 +9,9 @@
         end
       
         def matches?(response)
+          unless response.respond_to?:rendered_file
+            raise "The response has not yet rendered or is not a Response object. This matcher (render_template) must be defined after the controller action is called."
+          end
           @actual = response.rendered_file(!expected.include?('/'))
           actual == expected
         end


----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 03:18

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/49-11536-controller-should-render_template-must-be-defined-after-the-action#ticket-49-2

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-09-12 07:22

Message:
It's a bit too late for that Bryan. We're committed to not changing these. We could alias it, but I'd prefer to avoid going down that path. I think we need to figure out a way to give the right feedback when it's used incorrectly.

----------------------------------------------------------------------

Comment By: Bryan Helmkamp (brynary)
Date: 2007-09-12 07:14

Message:
Perhaps the matcher should be renamed from render_file to have_rendered_file. Thoughts?

If this sounds good, I'll write a patch.

----------------------------------------------------------------------

Comment By: courtenay 3 (court3nay)
Date: 2007-06-12 22:34

Message:
the patch doesn't actually work like I intended, but I can't see a way of checking 
that the order is correct

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11536&group_id=797

From noreply at rubyforge.org  Sun Nov 18 22:19:29 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 22:19:29 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-11726 ] Rspec on Rails does not use
	Active Record's fixture optimization
Message-ID: <20071119031929.64C09185859C@rubyforge.org>

Bugs item #11726, was opened at 2007-06-20 18:43
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11726&group_id=797

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: Rspec on Rails does not use Active Record's fixture optimization

Initial Comment:
Active Record fixtures are "cached" in a Hash based on the class. Since Rspec uses anonymous classes, there are no cache hits.

See fixtures.rb in ActiveRecord line 537.

If we can figure out how to utilize there cached fixtures, specs that use fixtures will be considerably faster.

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 22:19

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/51-11726-rspec-on-rails-does-not-use-active-record-s-fixture-optimization#ticket-51-2

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-09-06 07:43

Message:
Brian - in light of the current refactoring to concrete classes, I think this can be closed - yes?

----------------------------------------------------------------------

Comment By: Brian Takita (btakita)
Date: 2007-06-20 19:02

Message:
The other benefit to fixing this is using "all" of the
fixtures for every example would pretty much be free, as
long as transactional fixtures are used.

This means we don't need to worry about which fixtures need
to be loaded for the example.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11726&group_id=797

From noreply at rubyforge.org  Sun Nov 18 22:19:40 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 22:19:40 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-11562 ] Rake RCov task should work out
	of the box with --drb in spec.opts
Message-ID: <20071119031940.76851185859C@rubyforge.org>

Bugs item #11562, was opened at 2007-06-13 23:26
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11562&group_id=797

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: Rake RCov task should work out of the box with --drb in spec.opts

Initial Comment:

The rake task spec:rcov does not work if --drb is specified in spec.opts (in a rails project).  Here is the output:

euclid% rake spec:rcov
(in /Users/smtlaissezfaire/Sites/rails/changelog)
................................*..*..*...................*............. 
...................................

Finished in 5.751487 seconds

107 examples, 0 failures, 4 not implemented

No file to analyze was found. All the files loaded by rcov matched  
one of the
following expressions, and were thus ignored:
[/\A\/opt\/local\/lib/,
/\btc_[^.]*.rb/,
/_test\.rb\z/,
/\btest\//,
/\bvendor\//,
/\A\/opt\/local\/lib\/ruby\/gems\/1\.8\/gems\/rcov\-0\.8\.0\.2\/lib\/ 
rcov\/report\.rb\z/,
/spec/,
/\bvendor\//,
/\bconfig\//,
/\benvironment\//]

You can solve this by doing one or more of the following:
* rename the files not to be ignored so they don't match the above  
regexps
* use --include-file to give a list of patterns for files not to be  
ignored
* use --exclude-only to give the new list of regexps to match against
* structure your code as follows:
       test/test_*.rb  for the test cases
       lib/**/*.rb     for the target source code whose coverage you  
want
   making sure that the test/test_*.rb files are loading from lib/,  
e.g. by
   using the -Ilib command-line argument, adding
     $:.unshift File.join(File.dirname(__FILE__), "..", "lib")
   to test/test_*.rb, or running rcov via a Rakefile (read the RDoc
   documentation or README.rake in the source distribution).



But without --drb in spec.opts it works just fine.  Here is my setup:

Mac OS X.4.9

Fetching external item into 'vendor/rails'
External at revision 7014.

Fetching external item into 'vendor/plugins/rspec'
External at revision 2098.

Fetching external item into 'vendor/plugins/rspec_on_rails'
External at revision 2098.

Fetching external item into 'vendor/plugins/rails_rcov'
External at revision 12.

rcov gem @version 0.8.0.2


If you have some tips on how to write a spec for this, I'd be glad to write a patch.





----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 03:18

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/50-11562-rake-rcov-task-should-work-out-of-the-box-with-drb-in-spec-opts

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11562&group_id=797

From noreply at rubyforge.org  Sun Nov 18 22:20:24 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 22:20:24 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-12162 ] --drb in spec.opts
	causes`raise_controller_errors' not to be found and raises
	subsequent errors
Message-ID: <20071119032024.566D8185859A@rubyforge.org>

Bugs item #12162, was opened at 2007-07-10 11:54
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12162&group_id=797

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Edward Ocampo-Gooding (edwardog)
Assigned to: Nobody (None)
Summary: --drb in spec.opts causes`raise_controller_errors' not to be found and raises subsequent errors

Initial Comment:
Having --drb in spec.opts causes false-failures while running spec tasks against a running spec_server. Such failures resemble the following:

NameError in 'PurchaseController should use PurchaseController'
undefined local variable or method `raise_controller_errors' for [RSpec
example]:#<Class:0x69aa99c>
./spec/models/../spec_helper.rb:12:

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 22:20

Message:
http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/52-12162-drb-in-spec-opts-causes-raise_controller_errors-not-to-be-found-and-raises-subsequent-errors#ticket-52-2

----------------------------------------------------------------------

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-07-23 21:55

Message:
Could you attach the relevant code sample?  Could you also try reloading the spec server, and running the specs again?  I've encountered errors like this before when I've created a new Rails Model, but haven't yet reloaded the spec server.

----------------------------------------------------------------------

Comment By: Edward Ocampo-Gooding (edwardog)
Date: 2007-07-23 10:12

Message:
Relevent peripheral software:

* OS X 10.4.9
* Ruby 1.8.6
* RSpec-1.0.5 (r2081)
* Spec::Rails 1.0.5
* Rails 1.2.3

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-07-23 08:21

Message:
Before investigating this we need to know the versions of all 
relevant software you are using, for example:

* OS X 10.4.9
* Ruby 1.8.6
* RSpec 1.8.2 or RSpec trunk r1643
* Spec::Rails 1.8.2 or Spec::Rails tag r1234...
* Rails 1.2.3 or Rails edge r5645
* Whatever other relevant software.

Without this information it's like solving 1 equation (your 
question) with 5 unknown variables (the versions).

We strongly recommend that you use the latest released version of
RSpec, alternatively the subversion trunk (if you're the bleeding
edge kind of person).

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12162&group_id=797

From noreply at rubyforge.org  Sun Nov 18 22:20:31 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 22:20:31 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-11726 ] Rspec on Rails does not use
	Active Record's fixture optimization
Message-ID: <20071119032031.40C97185859C@rubyforge.org>

Bugs item #11726, was opened at 2007-06-20 22:43
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11726&group_id=797

Category: rails plugin
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: Rspec on Rails does not use Active Record's fixture optimization

Initial Comment:
Active Record fixtures are "cached" in a Hash based on the class. Since Rspec uses anonymous classes, there are no cache hits.

See fixtures.rb in ActiveRecord line 537.

If we can figure out how to utilize there cached fixtures, specs that use fixtures will be considerably faster.

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 03:19

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/51-11726-rspec-on-rails-does-not-use-active-record-s-fixture-optimization#ticket-51-2

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-09-06 11:43

Message:
Brian - in light of the current refactoring to concrete classes, I think this can be closed - yes?

----------------------------------------------------------------------

Comment By: Brian Takita (btakita)
Date: 2007-06-20 23:02

Message:
The other benefit to fixing this is using "all" of the
fixtures for every example would pretty much be free, as
long as transactional fixtures are used.

This means we don't need to worry about which fixtures need
to be loaded for the example.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11726&group_id=797

From noreply at rubyforge.org  Sun Nov 18 22:21:18 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 22:21:18 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-12404 ] Edge Rails breaks RSpec with
	newer link_to syntax
Message-ID: <20071119032118.CB76E185859A@rubyforge.org>

Bugs item #12404, was opened at 2007-07-19 03:03
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12404&group_id=797

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Marcus Crafter (crafterm)
Assigned to: Nobody (None)
Summary: Edge Rails breaks RSpec with newer link_to syntax

Initial Comment:
Hi All,

Hope all is going well.

In Edge Rails you can specify link to using:

link_to('path, @model)

as opposed to:

link_to('path', model_path(@model))

in 1.2 and earlier.

The newer syntax breaks rspec though if you have any helpers or view specs that test code that uses it with mock models. The error it prints is:

undefined method `polymorphic_path' for [Dynamically generated class
for RSpec example]:#<Class:0x26814f4>

Example to reproduce:

describe ApplicationHelper do
  it "should demo edge link_to problem" do
    mock = mock_model(User, :name => test)
    link_to(mock.name, mock).should == '<a href="/users/1000">test</a>'
  end
end

I've been able to fix this with the following monkey patch:

module Spec
  module Rails
    module DSL
      class EvalContext < Spec::Rails::TestCase
        def polymorphic_path(uri)
          "/#{uri.class.to_s.underscore.pluralize}/#{uri.id}"
        end
      end
    end
  end
end

However there may be a more appropriate solution? Would be great to get this fixed, please let me know if there's anything else I can do.

Cheers,

Marcus


----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 22:21

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/53-12404-edge-rails-breaks-rspec-with-newer-link_to-syntax#ticket-53-2

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-07-27 19:16

Message:
I took a look at this. The method as you've defined it would always return what is essentially the "show" path. The whole magic of polymorphic_path is that it renders a different url based on the state of the object. I think this would lead to people getting frustrated using rspec to describe helper methods like the one you are trying to deal with, with objects that are in varying states, and getting unexpected results.

With that in mind, a more robust solution *would* be to include ActionController::PolymorphicRoutes in the helper examples (that's where polymorphic_path gets defined) - but this creates a new problem, which is that polymorphic_path ends up using named routes that don't exist in scope either.

Anybody have any suggestions here?

David


----------------------------------------------------------------------

Comment By: Marcus Crafter (crafterm)
Date: 2007-07-22 19:57

Message:
Hi David,

My apologies, I've attached a tar.bz2 archive that includes
a working example of the issue.

Please extract the polymorphic-path-example.tar.bz2, and run
the notes_helper_spec.rb spec, or simply run rake spec after
creating the test database, and you'll see the error.

I haven't included rails, or rspec with this example, in the
vendor directory, I've symlinked rails to the latest trunk
(rev 7209), and in the plugins directory rspec/rpec_on_rails
(rev 2181).

The notes_helper_spec.rb includes the fix I wrote but I'm
unsure if this is the correct solution. I'm happy to write a
patch for this for rspec itself if you're happy with it.

Cheers,

Marcus

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-07-22 16:03

Message:
I'm not able to reproduce this error using the example you've provided. Please submit an example that we can get to fail running rspec's own examples. See http://rspec.rubyforge.org/community/contribute.html for more information.

Thanks

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12404&group_id=797

From noreply at rubyforge.org  Sun Nov 18 22:25:26 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 22:25:26 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-12162 ] --drb in spec.opts
	causes`raise_controller_errors' not to be found and raises
	subsequent errors
Message-ID: <20071119032526.AAFD9185859A@rubyforge.org>

Bugs item #12162, was opened at 2007-07-10 15:54
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12162&group_id=797

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Edward Ocampo-Gooding (edwardog)
Assigned to: Nobody (None)
Summary: --drb in spec.opts causes`raise_controller_errors' not to be found and raises subsequent errors

Initial Comment:
Having --drb in spec.opts causes false-failures while running spec tasks against a running spec_server. Such failures resemble the following:

NameError in 'PurchaseController should use PurchaseController'
undefined local variable or method `raise_controller_errors' for [RSpec
example]:#<Class:0x69aa99c>
./spec/models/../spec_helper.rb:12:

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 03:20

Message:
http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/52-12162-drb-in-spec-opts-causes-raise_controller_errors-not-to-be-found-and-raises-subsequent-errors#ticket-52-2

----------------------------------------------------------------------

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-07-24 01:55

Message:
Could you attach the relevant code sample?  Could you also try reloading the spec server, and running the specs again?  I've encountered errors like this before when I've created a new Rails Model, but haven't yet reloaded the spec server.

----------------------------------------------------------------------

Comment By: Edward Ocampo-Gooding (edwardog)
Date: 2007-07-23 14:12

Message:
Relevent peripheral software:

* OS X 10.4.9
* Ruby 1.8.6
* RSpec-1.0.5 (r2081)
* Spec::Rails 1.0.5
* Rails 1.2.3

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-07-23 12:21

Message:
Before investigating this we need to know the versions of all 
relevant software you are using, for example:

* OS X 10.4.9
* Ruby 1.8.6
* RSpec 1.8.2 or RSpec trunk r1643
* Spec::Rails 1.8.2 or Spec::Rails tag r1234...
* Rails 1.2.3 or Rails edge r5645
* Whatever other relevant software.

Without this information it's like solving 1 equation (your 
question) with 5 unknown variables (the versions).

We strongly recommend that you use the latest released version of
RSpec, alternatively the subversion trunk (if you're the bleeding
edge kind of person).

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12162&group_id=797

From noreply at rubyforge.org  Sun Nov 18 22:25:47 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 22:25:47 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-12404 ] Edge Rails breaks RSpec with
	newer link_to syntax
Message-ID: <20071119032547.9026E1858598@rubyforge.org>

Bugs item #12404, was opened at 2007-07-19 07:03
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12404&group_id=797

Category: rails plugin
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Marcus Crafter (crafterm)
Assigned to: Nobody (None)
Summary: Edge Rails breaks RSpec with newer link_to syntax

Initial Comment:
Hi All,

Hope all is going well.

In Edge Rails you can specify link to using:

link_to('path, @model)

as opposed to:

link_to('path', model_path(@model))

in 1.2 and earlier.

The newer syntax breaks rspec though if you have any helpers or view specs that test code that uses it with mock models. The error it prints is:

undefined method `polymorphic_path' for [Dynamically generated class
for RSpec example]:#<Class:0x26814f4>

Example to reproduce:

describe ApplicationHelper do
  it "should demo edge link_to problem" do
    mock = mock_model(User, :name => test)
    link_to(mock.name, mock).should == '<a href="/users/1000">test</a>'
  end
end

I've been able to fix this with the following monkey patch:

module Spec
  module Rails
    module DSL
      class EvalContext < Spec::Rails::TestCase
        def polymorphic_path(uri)
          "/#{uri.class.to_s.underscore.pluralize}/#{uri.id}"
        end
      end
    end
  end
end

However there may be a more appropriate solution? Would be great to get this fixed, please let me know if there's anything else I can do.

Cheers,

Marcus


----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 03:21

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/53-12404-edge-rails-breaks-rspec-with-newer-link_to-syntax#ticket-53-2

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-07-27 23:16

Message:
I took a look at this. The method as you've defined it would always return what is essentially the "show" path. The whole magic of polymorphic_path is that it renders a different url based on the state of the object. I think this would lead to people getting frustrated using rspec to describe helper methods like the one you are trying to deal with, with objects that are in varying states, and getting unexpected results.

With that in mind, a more robust solution *would* be to include ActionController::PolymorphicRoutes in the helper examples (that's where polymorphic_path gets defined) - but this creates a new problem, which is that polymorphic_path ends up using named routes that don't exist in scope either.

Anybody have any suggestions here?

David


----------------------------------------------------------------------

Comment By: Marcus Crafter (crafterm)
Date: 2007-07-22 23:57

Message:
Hi David,

My apologies, I've attached a tar.bz2 archive that includes
a working example of the issue.

Please extract the polymorphic-path-example.tar.bz2, and run
the notes_helper_spec.rb spec, or simply run rake spec after
creating the test database, and you'll see the error.

I haven't included rails, or rspec with this example, in the
vendor directory, I've symlinked rails to the latest trunk
(rev 7209), and in the plugins directory rspec/rpec_on_rails
(rev 2181).

The notes_helper_spec.rb includes the fix I wrote but I'm
unsure if this is the correct solution. I'm happy to write a
patch for this for rspec itself if you're happy with it.

Cheers,

Marcus

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-07-22 20:03

Message:
I'm not able to reproduce this error using the example you've provided. Please submit an example that we can get to fail running rspec's own examples. See http://rspec.rubyforge.org/community/contribute.html for more information.

Thanks

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12404&group_id=797

From noreply at rubyforge.org  Sun Nov 18 22:26:32 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 22:26:32 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-12648 ] rspec_on_rails without a database
Message-ID: <20071119032632.53D1B1858598@rubyforge.org>

Bugs item #12648, was opened at 2007-07-27 18:26
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12648&group_id=797

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Nobody (None)
Summary: rspec_on_rails without a database

Initial Comment:
With this setup:

RSpec (1.0.5 or trunk r2183)
Edge Rails (r7245) 

And following these instructions from http://rubyforge.org/tracker/?func=detail&group_id=797&aid=6523&atid=3152:

Remove config/database.yml.
Tell Rails not to use AR in config/environment.rb.

This no longer works. With a new rails app configured that way, I get the following error:

undefined method `connected?' for ActiveRecord::Base:Class
/Users/david/projects/ruby/nodb/vendor/rails/activerecord/lib/active_record/base.rb:1261:in `method_missing'
/Users/david/projects/ruby/nodb/vendor/rails/actionpack/lib/action_controller/benchmarking.rb:48:in `render'
/Users/david/projects/ruby/nodb/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/controller.rb:70:in `render'
/Users/david/projects/ruby/nodb/app/controllers/things_controller.rb:3:in `index'
/Users/david/projects/ruby/nodb/vendor/rails/actionpack/lib/action_controller/base.rb:1136:in `send'
/Users/david/projects/ruby/nodb/vendor/rails/actionpack/lib/action_controller/base.rb:1136:in `perform_action_without_filters'
/Users/david/projects/ruby/nodb/vendor/rails/actionpack/lib/action_controller/filters.rb:695:in `call_filters'
/Users/david/projects/ruby/nodb/vendor/rails/actionpack/lib/action_controller/filters.rb:687:in `perform_action_without_benchmark'
/Users/david/projects/ruby/nodb/vendor/rails/actionpack/lib/action_controller/benchmarking.rb:68:in `perform_action_without_rescue'
/opt/local/lib/ruby/1.8/benchmark.rb:293:in `measure'
/Users/david/projects/ruby/nodb/vendor/rails/actionpack/lib/action_controller/benchmarking.rb:68:in `perform_action_without_rescue'
/Users/david/projects/ruby/nodb/vendor/rails/actionpack/lib/action_controller/rescue.rb:133:in `perform_action'
/Users/david/projects/ruby/nodb/vendor/rails/actionpack/lib/action_controller/base.rb:494:in `send'
/Users/david/projects/ruby/nodb/vendor/rails/actionpack/lib/action_controller/base.rb:494:in `process_without_filters'
/Users/david/projects/ruby/nodb/vendor/rails/actionpack/lib/action_controller/filters.rb:683:in `process_without_session_management_support'
/Users/david/projects/ruby/nodb/vendor/rails/actionpack/lib/action_controller/session_management.rb:122:in `process_without_test'
/Users/david/projects/ruby/nodb/vendor/rails/actionpack/lib/action_controller/test_process.rb:15:in `process'
/Users/david/projects/ruby/nodb/vendor/rails/actionpack/lib/action_controller/test_process.rb:394:in `process'
/Users/david/projects/ruby/nodb/vendor/rails/actionpack/lib/action_controller/test_process.rb:365:in `get'
./spec/controllers/things_controller_spec.rb:5:
/Users/david/projects/ruby/nodb/vendor/plugins/rspec/lib/spec/dsl/example.rb:81:in `instance_eval'
/Users/david/projects/ruby/nodb/vendor/plugins/rspec/lib/spec/dsl/example.rb:81:in `run_example'
/Users/david/projects/ruby/nodb/vendor/plugins/rspec/lib/spec/dsl/example.rb:26:in `run'
/opt/local/lib/ruby/1.8/timeout.rb:48:in `timeout'
/Users/david/projects/ruby/nodb/vendor/plugins/rspec/lib/spec/dsl/example.rb:24:in `run'
/Users/david/projects/ruby/nodb/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:81:in `run'
/Users/david/projects/ruby/nodb/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:75:in `each'
/Users/david/projects/ruby/nodb/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:75:in `run'
/Users/david/projects/ruby/nodb/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:58:in `run_behaviours'
/Users/david/projects/ruby/nodb/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:57:in `each'
/Users/david/projects/ruby/nodb/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:57:in `run_behaviours'
/Users/david/projects/ruby/nodb/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:21:in `run'
/Users/david/projects/ruby/nodb/vendor/plugins/rspec/lib/spec/runner/command_line.rb:17:in `run'
script/spec:4:

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 22:26

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/54-12648-rspec_on_rails-without-a-database

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12648&group_id=797

From noreply at rubyforge.org  Sun Nov 18 22:27:15 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 22:27:15 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-12648 ] rspec_on_rails without a database
Message-ID: <20071119032715.9E877185859A@rubyforge.org>

Bugs item #12648, was opened at 2007-07-27 22:26
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12648&group_id=797

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Nobody (None)
Summary: rspec_on_rails without a database

Initial Comment:
With this setup:

RSpec (1.0.5 or trunk r2183)
Edge Rails (r7245) 

And following these instructions from http://rubyforge.org/tracker/?func=detail&group_id=797&aid=6523&atid=3152:

Remove config/database.yml.
Tell Rails not to use AR in config/environment.rb.

This no longer works. With a new rails app configured that way, I get the following error:

undefined method `connected?' for ActiveRecord::Base:Class
/Users/david/projects/ruby/nodb/vendor/rails/activerecord/lib/active_record/base.rb:1261:in `method_missing'
/Users/david/projects/ruby/nodb/vendor/rails/actionpack/lib/action_controller/benchmarking.rb:48:in `render'
/Users/david/projects/ruby/nodb/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/controller.rb:70:in `render'
/Users/david/projects/ruby/nodb/app/controllers/things_controller.rb:3:in `index'
/Users/david/projects/ruby/nodb/vendor/rails/actionpack/lib/action_controller/base.rb:1136:in `send'
/Users/david/projects/ruby/nodb/vendor/rails/actionpack/lib/action_controller/base.rb:1136:in `perform_action_without_filters'
/Users/david/projects/ruby/nodb/vendor/rails/actionpack/lib/action_controller/filters.rb:695:in `call_filters'
/Users/david/projects/ruby/nodb/vendor/rails/actionpack/lib/action_controller/filters.rb:687:in `perform_action_without_benchmark'
/Users/david/projects/ruby/nodb/vendor/rails/actionpack/lib/action_controller/benchmarking.rb:68:in `perform_action_without_rescue'
/opt/local/lib/ruby/1.8/benchmark.rb:293:in `measure'
/Users/david/projects/ruby/nodb/vendor/rails/actionpack/lib/action_controller/benchmarking.rb:68:in `perform_action_without_rescue'
/Users/david/projects/ruby/nodb/vendor/rails/actionpack/lib/action_controller/rescue.rb:133:in `perform_action'
/Users/david/projects/ruby/nodb/vendor/rails/actionpack/lib/action_controller/base.rb:494:in `send'
/Users/david/projects/ruby/nodb/vendor/rails/actionpack/lib/action_controller/base.rb:494:in `process_without_filters'
/Users/david/projects/ruby/nodb/vendor/rails/actionpack/lib/action_controller/filters.rb:683:in `process_without_session_management_support'
/Users/david/projects/ruby/nodb/vendor/rails/actionpack/lib/action_controller/session_management.rb:122:in `process_without_test'
/Users/david/projects/ruby/nodb/vendor/rails/actionpack/lib/action_controller/test_process.rb:15:in `process'
/Users/david/projects/ruby/nodb/vendor/rails/actionpack/lib/action_controller/test_process.rb:394:in `process'
/Users/david/projects/ruby/nodb/vendor/rails/actionpack/lib/action_controller/test_process.rb:365:in `get'
./spec/controllers/things_controller_spec.rb:5:
/Users/david/projects/ruby/nodb/vendor/plugins/rspec/lib/spec/dsl/example.rb:81:in `instance_eval'
/Users/david/projects/ruby/nodb/vendor/plugins/rspec/lib/spec/dsl/example.rb:81:in `run_example'
/Users/david/projects/ruby/nodb/vendor/plugins/rspec/lib/spec/dsl/example.rb:26:in `run'
/opt/local/lib/ruby/1.8/timeout.rb:48:in `timeout'
/Users/david/projects/ruby/nodb/vendor/plugins/rspec/lib/spec/dsl/example.rb:24:in `run'
/Users/david/projects/ruby/nodb/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:81:in `run'
/Users/david/projects/ruby/nodb/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:75:in `each'
/Users/david/projects/ruby/nodb/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:75:in `run'
/Users/david/projects/ruby/nodb/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:58:in `run_behaviours'
/Users/david/projects/ruby/nodb/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:57:in `each'
/Users/david/projects/ruby/nodb/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:57:in `run_behaviours'
/Users/david/projects/ruby/nodb/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:21:in `run'
/Users/david/projects/ruby/nodb/vendor/plugins/rspec/lib/spec/runner/command_line.rb:17:in `run'
script/spec:4:

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 03:26

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/54-12648-rspec_on_rails-without-a-database

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12648&group_id=797

From noreply at rubyforge.org  Sun Nov 18 22:36:29 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 22:36:29 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-12699 ] Shared Specs are not reloaded
	when using DRb
Message-ID: <20071119033629.A2D1D1858598@rubyforge.org>

Bugs item #12699, was opened at 2007-07-30 16:09
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12699&group_id=797

Category: Autotest
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: Shared Specs are not reloaded when using DRb

Initial Comment:
If I change the spec, it does not reload on the spec_server.

To reproduce, make a spec, create a spec and run it using the spec_server.

describe "DRb", :shared => true do
  it "should reload shared specs" do
    true.should == false
  end
end

describe "DRb reloading" do
  it_should_behave_like "DRb"
end

Now edit the shared spec:

describe "DRb", :shared => true do
  it "should reload shared specs" do
    true.should == true
  end
end

There will still be a failure.

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 22:36

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/55-12699-shared-specs-are-not-reloaded-when-using-drb

----------------------------------------------------------------------

Comment By: Brian Takita (btakita)
Date: 2007-07-30 16:12

Message:
To fix this for my project I edited spec_server:

module Spec
  module Runner
    class RailsSpecServer
      def run(args, stderr, stdout)
        $stdout = stdout
        $stderr = stderr

        Spec::DSL::Behaviour.shared_behaviours.clear
        Dependencies.mechanism = :load
        Dependencies.clear
        
        ::Spec::Runner::CommandLine.run(args, stderr,
stdout, false, true)
      end
    end
  end
end


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12699&group_id=797

From noreply at rubyforge.org  Sun Nov 18 22:41:46 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 22:41:46 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-12699 ] Shared Specs are not reloaded
	when using DRb
Message-ID: <20071119034146.D96F61858598@rubyforge.org>

Bugs item #12699, was opened at 2007-07-30 20:09
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12699&group_id=797

Category: Autotest
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: Shared Specs are not reloaded when using DRb

Initial Comment:
If I change the spec, it does not reload on the spec_server.

To reproduce, make a spec, create a spec and run it using the spec_server.

describe "DRb", :shared => true do
  it "should reload shared specs" do
    true.should == false
  end
end

describe "DRb reloading" do
  it_should_behave_like "DRb"
end

Now edit the shared spec:

describe "DRb", :shared => true do
  it "should reload shared specs" do
    true.should == true
  end
end

There will still be a failure.

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 03:36

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/55-12699-shared-specs-are-not-reloaded-when-using-drb

----------------------------------------------------------------------

Comment By: Brian Takita (btakita)
Date: 2007-07-30 20:12

Message:
To fix this for my project I edited spec_server:

module Spec
  module Runner
    class RailsSpecServer
      def run(args, stderr, stdout)
        $stdout = stdout
        $stderr = stderr

        Spec::DSL::Behaviour.shared_behaviours.clear
        Dependencies.mechanism = :load
        Dependencies.clear
        
        ::Spec::Runner::CommandLine.run(args, stderr,
stdout, false, true)
      end
    end
  end
end


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12699&group_id=797

From noreply at rubyforge.org  Sun Nov 18 22:59:14 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 22:59:14 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-12760 ] Autotest regexp no longer
	matches new pretty output
Message-ID: <20071119035914.B72A21858598@rubyforge.org>

Bugs item #12760, was opened at 2007-08-01 21:29
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12760&group_id=797

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jay Levitt (jaylev)
Assigned to: Nobody (None)
Summary: Autotest regexp no longer matches new pretty output

Initial Comment:
Aslak changed lib/spec/matchers/operator_matcher.rb in July to be nice and pretty, but lib/autotest/rspec.rb hasn't been updated to match it, so the output from autotest is now just blank lines when a should == expectation fails.

describe "it" do
  it "doesn't work" do
    1.should == 2
  end
end

Windows XP SP2 under cygwin
ruby 1.8.6 [i386-cygwin]
rspec r2189

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 22:59

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/56-12760-autotest-regexp-no-longer-matches-new-pretty-output

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-09-23 16:55

Message:
Is this still a problem?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12760&group_id=797

From noreply at rubyforge.org  Sun Nov 18 23:00:08 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 23:00:08 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-12898 ] render should support :inline
Message-ID: <20071119040008.AB6321858598@rubyforge.org>

Bugs item #12898, was opened at 2007-08-07 21:24
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12898&group_id=797

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jay Levitt (jaylev)
Assigned to: Nobody (None)
Summary: render should support :inline

Initial Comment:
The version of render in rspec_on_rails/lib/rails/dsl/behaviour/view.rb supports only rendering a template, a partial, or a file.  The ability to render :inline would be useful for such things as testing custom FormBuilders, e.g.:

describe LabelledBuilder do

  it "should let me create a text field" do
    object = mock(object)
    object.stub!(:attribute).and_return("Test String")

     render :inline =>
      "<% form_for(@object, :builder => LabelledBuilder) do |f| -%>
        <%= f.text_field :attribute %>
       <% end %>"

     response.should have_tag("label")
  end
end

results in:

Unhandled render type in view spec.



----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 23:00

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/57-12898-render-should-support-inline

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12898&group_id=797

From noreply at rubyforge.org  Sun Nov 18 23:01:26 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 23:01:26 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-12963 ] RESTfully generated
	(polymorphic) helpers require arguments in rspec but not in rails
Message-ID: <20071119040126.2525B1858598@rubyforge.org>

Bugs item #12963, was opened at 2007-08-10 10:01
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12963&group_id=797

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Lance Carlson (lancelot)
Assigned to: Nobody (None)
Summary: RESTfully generated (polymorphic) helpers require arguments in rspec but not in rails

Initial Comment:
My view tests fail when I try to use the polymorphic helpers in rails and report back an error like this:

ActionView::TemplateError in 'Edit Artist Page should render the edit
artist form'
label_artist_url failed to generate from {:controller=>"artists",
:action=>"show"} - you may have ambiguous routes, or you may need to
supply additional parameters for this route.  content_url has the
following required parameters: ["labels", :label_id, "artists", :id] -
are they all satisfied?
On line #3 of app/views/artists/edit.rhtml

   1: <h1>Editing artist</h1>
   2:
   3: <% form_tag label_artist_path, :method => :put do %>
   4:   <%= render :partial => 'form' %>
   5:   <%= submit_tag 'Save' %>
   6: <% end %>

I could stub out the method, but then I wouldn't be testing the view in its entirety. I could provide the arguments that it asks for and the tests passes. Forcing me to add the arguments adds unnecessary noise to the code and should not be a requirement to get tests to pass in rspec. I will try this without nested routes and see if the same problem arises and will also try to see if I can make a patch for this. 

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 23:01

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/58-12963-restfully-generated-polymorphic-helpers-require-arguments-in-rspec-but-not-in-rails

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12963&group_id=797

From noreply at rubyforge.org  Sun Nov 18 23:03:09 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 23:03:09 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-13039 ] exceptions in views give a noisy
	stack trace
Message-ID: <20071119040309.264291858598@rubyforge.org>

Bugs item #13039, was opened at 2007-08-13 21:32
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13039&group_id=797

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jay Levitt (jaylev)
Assigned to: Nobody (None)
Summary: exceptions in views give a noisy stack trace

Initial Comment:
# spec/views/bad_spec.rb
require File.dirname(__FILE__) + '/../../spec_helper'

describe "test" do
  it "test" do
    m = mock("test")
    assigns[:m] = m
    render '/users/test'
  end
end

# app/views/user/test.html.erb
<% @m.blah %>

Result: The stack trace isn't cleaned by backtrace_tweaker, because instead of e.backtrace being an array of strings, each with one line, it's an array with one element - all the lines of the backtrace concatenated with "\n" separators.

I cannot figure out where this is happening.  The exception as re-raised by ActionView::Base#render_file still has a proper array, but by the time it gets to Spec::DSL::Example#run_example, it's a single-element array.  I don't know enough about exceptions to know how to find every rescue/re-raise of the exception...



----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 23:03

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/59-13039-exceptions-in-views-give-a-noisy-stack-trace#ticket-59-2

----------------------------------------------------------------------

Comment By: Jay Levitt (jaylev)
Date: 2007-08-13 22:06

Message:
OK, a little set_trace_func and now I get it.  When
ActionView::Base#render_file reraises the exception, it's
actually setting the backtrace to template_source, which I
guess must come from ERB, and which is newline-separated. 
However, it changes the exception type to TemplateError, and
stashes the original exception in e.original_exception.

So we could do a few things:

1. Parse the newlines out if this is a TemplateError.
2. Look at e.original_exception.backtrace instead of
e.backtrace if this is a TemplateError.
3. Some combination of the two.  That'd only be necessary if
the two backtraces could ever differ; I have no idea if that
could happen or not.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13039&group_id=797

From noreply at rubyforge.org  Sun Nov 18 23:05:33 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 23:05:33 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-13141 ] backtrace should only be tweaked
	at end, not beginning
Message-ID: <20071119040533.87C371858598@rubyforge.org>

Bugs item #13141, was opened at 2007-08-16 17:15
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13141&group_id=797

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jay Levitt (jaylev)
Assigned to: Nobody (None)
Summary: backtrace should only be tweaked at end, not beginning

Initial Comment:
Imagine this failing view spec:

describe "this spec" do
  it "should fail" do
    form_for(nil,nil){}
  end
end

The output is:

NoMethodError in 'LabelledBuilderHelper providing labelled_form_for should fail'
You have a nil object when you didn't expect it!
You might have expected an instance of Array.
The error occurred while evaluating nil.<<
./spec/helpers/labelled_builder_helper_spec.rb:4:
script/spec:4:

But of course there is no << in line 4 of this spec.  The error happened inside form_for, and thus the error message is tweaked away.

I think tweak_backtrace should only eliminate those matching lines that occur at the end of the backtrace - i.e. the many parent classes of rails.  Ya?


----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 23:05

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/60-13141-backtrace-should-only-be-tweaked-at-end-not-beginning#ticket-60-2

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-21 14:39

Message:
Great. Thanks for playing!

----------------------------------------------------------------------

Comment By: Ryan Bates (ryanb)
Date: 2007-08-21 14:35

Message:
I understand now. Sorry for the confusion. I see there's a separate ticket [#13020] which (I think) covers the problem I am having. I'll post over there.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-21 14:27

Message:
Jay's problem is that the filtered backtrace is lying about the location of the error. The backtrace you posted is a complete backtrace and tells you exactly where to look to debug the problem. Two completely separate issues.

----------------------------------------------------------------------

Comment By: Ryan Bates (ryanb)
Date: 2007-08-21 14:22

Message:
Is this problem unrelated to the backtrace tweaker then? From my understanding that just removes some lines of the backtrace.

Either way, I'm sure my problem is the same as mentioned in this ticket. It's a helper spec and I'm getting the same error message. Here's the full backtrace: http://pastie.caboo.se/89745

I'm on edge rails as you can probably tell. Maybe that is part of the problem?

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-21 13:53

Message:
Ryan - this is a request for a different backtrace, not a full backtrace. You can already get a full backtrace with the -b option.

----------------------------------------------------------------------

Comment By: Ryan Bates (ryanb)
Date: 2007-08-21 13:39

Message:
+1

I'm running into this problem and it makes it very difficult to debug without a full stack trace.


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13141&group_id=797

From noreply at rubyforge.org  Sun Nov 18 23:06:43 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 23:06:43 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-13208 ] Specdoc outputs wrong spec names
	with drbserver
Message-ID: <20071119040643.3E5561858598@rubyforge.org>

Bugs item #13208, was opened at 2007-08-19 17:26
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13208&group_id=797

Category: None
Group: None
Status: Open
Resolution: None
Priority: 4
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: Specdoc outputs wrong spec names with drbserver

Initial Comment:

In a rails project (trunk, rev. 7345, ruby 1.8.6, Mac OS X, Rspec & rspec on rails frozen in /vendor/plugins at current release, 1.0.8), with the following spec.opts:

--colour

--loadby mtime
--reverse
--drb
--format specdoc

The output looks as follows:

ptolemy# rake spec
(in /Users/smt/src/web/urbis/branches/rails_2.0_integration)

      *******************************************************************
      * config.breakpoint_server has been deprecated and has no effect. *
      *******************************************************************
      

#<DRb::DRbUnknown:0x14e7298>
- should have the unit name
- should have the keyword
- should ensure that each unit_name is unique

#<DRb::DRbUnknown:0x14b4604>
- should add the error 'Wrong category for this item' on validation of the attempt if the goal's category is equal to the item's category (PENDING: Not Yet Implemented)
- should add the error 'Wrong category for this item' on validation of the attempt if the goal's category is nil (PENDING: Not Yet Implemented)


Obviously the class names/description blocks are not being displayed properly.




----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 23:06

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/61-13208-specdoc-outputs-wrong-spec-names-with-drbserver#ticket-61-2

----------------------------------------------------------------------

Comment By: Chris Scharf (scharfie)
Date: 2007-11-08 14:20

Message:
I believe I have found the fix for this.  In the behaviour.rb file for RSpec (rspec/lib/spec/dsl/behaviour.rb) change the following line in the run method:

  reporter.add_behaviour(@description)

to 

  reporter.add_behaviour(@description.to_s)

----------------------------------------------------------------------

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-08-20 04:43

Message:
This is happening because Behaviour is not serializable. I'll look into this one.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13208&group_id=797

From noreply at rubyforge.org  Sun Nov 18 23:08:53 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 23:08:53 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-13433 ] RSpec hangs when used with QtRuby
Message-ID: <20071119040853.9A3271858598@rubyforge.org>

Bugs item #13433, was opened at 2007-08-27 15:30
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13433&group_id=797

Category: mock module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Stefano Crocco (stcrocco)
Assigned to: Nobody (None)
Summary: RSpec hangs when used with QtRuby

Initial Comment:
Creating mocks/stubs for a method called 'type' and requiring (even if not actually using) QtRuby makes spec (or rake, when using the Spec task) hang indefinitly. This doesn't happen when mocking any other method or when using a mocking framework different from RSpec's default framework (at least, it works using flexmock).

This is the smallest piece of code which causes the problem:

require 'Qt4'

describe 'something' do

  it 'should work passing the :type parameter' do
    m = mock('test')
    m.should_receive(:type)
  end

end

The attached file contains the backtrace obtained running spec -b on the file prova.rb containing the above code (obtained after using Ctrl+C to stop spec after it hangs).

System description:

gentoo linux (kernel 2.6.21-gentoo-r3)
ruby: ruby 1.8.6 (2007-06-07 patchlevel 36)
rspec: RSpec-1.0.8 (r2338) (gem) (RSpec 1.0.5 didn't cause this problem)
Qt: 4.3.1 open source or Qt 3.3.8 (the problem happens with both qt3 and qt4)
QtRuby: 1.4.9 (for Qt4) and Korundum 3.5.5 (for KDE/Qt3)



----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 23:08

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/62-13433-rspec-hangs-when-used-with-qtruby#ticket-62-1



----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13433&group_id=797

From noreply at rubyforge.org  Sun Nov 18 23:17:42 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 23:17:42 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-13461 ] spec_ui ScreenshotFormatter
	selenium examples don't work
Message-ID: <20071119041742.841DD185859C@rubyforge.org>

Bugs item #13461, was opened at 2007-08-28 11:34
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13461&group_id=797

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jean-Michel Garnier (garnierjm)
Assigned to: Nobody (None)
Summary: spec_ui ScreenshotFormatter selenium examples don't work

Initial Comment:
The selenium examples in rspec/spec_ui/examples/selenium/spec/selenium/find_rspecs_homepage_spec.rb
don't work anymore since the upgrade to 1.0.8

Stacktrace:

NoMethodError in 'Google's search page I should find rspec's home page when I search for rspec'
undefined method `take_screenshot_of' for nil:NilClass
/spec_ui/examples/selenium/spec/selenium/../spec_helper.rb:21:
/spec_ui/examples/selenium/spec/selenium/find_rspecs_homepage_spec.rb:18:

This is due to the fact that Spec::Ui::ScreenshotFormatter is now a Singleton and should be initialized.

I have attached a patch which adds the initialization of Spec::Ui::ScreenshotFormatter:

Spec::Ui::ScreenshotFormatter.new(File.dirname(__FILE__) + '/../specs.html')

 in the before :all of spec_helper because it seemed like a logical place.

Since this bug happens in the examples, I haven't written any spec. However, I can write some if necessary.

I am not using Watir since I am on Ubuntu but I guess there is the same problem.

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 23:17

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/63-13461-spec_ui-screenshotformatter-selenium-examples-don-t-work#ticket-63-2

----------------------------------------------------------------------

Comment By: Jean-Michel Garnier (garnierjm)
Date: 2007-08-29 13:23

Message:
Sorry AslaK, with a k.

Please ignore the first patch, I had made a stupid mistake :-(

Reading at the code it doesn't look very simple, why not
replacing the initialization by a simple call or by a
default value (with documentation) so it's transparent for
the user

----------------------------------------------------------------------

Comment By: Jean-Michel Garnier (garnierjm)
Date: 2007-08-29 11:51

Message:
Sorry Asla, I did read the instructions
(http://rspec.rubyforge.org/community/contribute.html) but I
forgot the checkbox ;-)

I am going to submit a couple of patch for spec_ui selenium
today.

----------------------------------------------------------------------

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-08-28 15:14

Message:
Where's the patch? Don't forget to check the checkbox. For the future, please submit patches against the patches tracker - we  keep a closer eye on that than bugs.

----------------------------------------------------------------------

Comment By: Jean-Michel Garnier (garnierjm)
Date: 2007-08-28 11:56

Message:
The patch is the for
/spec_ui/examples/selenium/spec/selenium/../spec_helper.rb
and has been generated with netbeans 

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13461&group_id=797

From noreply at rubyforge.org  Sun Nov 18 23:18:29 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 23:18:29 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-13708 ] Revision 2482 killed custom
	assertions in spec:ui
Message-ID: <20071119041829.39F27185859C@rubyforge.org>

Bugs item #13708, was opened at 2007-09-06 04:16
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13708&group_id=797

Category: None
Group: None
Status: Open
Resolution: Accepted
Priority: 3
Submitted By: Marcus Ahnve (mahnve)
Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: Revision 2482 killed custom assertions in spec:ui

Initial Comment:
Rev 2482 did something that takes our custom expectations for Selenium using spec:ui out of the call chain - they are no longer called at all. In revision 2481 this works.

I've tried running the Watir examples, which custom expectations we basically copied, and they seem broken too. 

I am trying to locate what in that rev that causes this to happen, but I have so far been unsuccessful.

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 23:18

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/64-13708-revision-2482-killed-custom-assertions-in-spec-ui#ticket-64-2

----------------------------------------------------------------------

Comment By: Marcus Ahnve (mahnve)
Date: 2007-09-16 16:07

Message:
Ah yes. I was only thinking of stories mapping to
integration tests - but they are currently declared as such. 

Your original proposal is probably good. But I just
remembered that our spec:ui specs are in a separate spec_ui
folder, and not under the spec folder. 

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-09-16 15:12

Message:
Rails matchers everywhere under the spec directory on a Rails project, yes. It even sounds reasonable, but obviously presents us with this problem.

re: Stories. 2 things: 1 - stories are going to live under RAILS_ROOT/stories, not RAILS_ROOT/specs. 2 - they wrap rails IntegrationTest, so they DO include the Rails matchers.

Cheers,
David

----------------------------------------------------------------------

Comment By: Marcus Ahnve (mahnve)
Date: 2007-09-16 15:08

Message:
Did you mean that the other RFE wanted *rails* matchers
available everywhere? 

Your proposed solution sounds like a good compromise. Would
it include stories/ as well?

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-09-13 02:42

Message:
Ah yes - this was a fix to another RFE that wanted the rspec matchers available everywhere under spec.

Need to think about how I want to approach this. Probably undo the other feature so you get rails goodies for free in spec/models, spec/views, spec/controllers, spec/helpers, and spec/lib, but anywhere else you have explicitly say :behaviour_type => :rails.

WDYT?

----------------------------------------------------------------------

Comment By: Marcus Ahnve (mahnve)
Date: 2007-09-06 04:39

Message:
I found the line causing this to happen: 

In 

rspec_on_rails/lib/spec/rails/dsl/behaviour/rails_example.rb,
the line  

Spec::DSL::BehaviourFactory.add_behaviour_class(:default, self)

does something that reoverrides our custom expectations. 

The problem seems to be that the rspec_on_rails expectations
by the call above are defined after our custom definitions.
It therefore only affects our own "have_tag" etc, which have
a expectation with the same name in RSpec On Rails.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13708&group_id=797

From noreply at rubyforge.org  Sun Nov 18 23:26:38 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 23:26:38 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-13741 ] Helper specs oddities,
	compared to controller and other specs
Message-ID: <20071119042638.404351858598@rubyforge.org>

Bugs item #13741, was opened at 2007-09-07 04:05
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13741&group_id=797

Category: mock module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Johan S?rensen (johansorensen)
Assigned to: Nobody (None)
Summary: Helper specs oddities, compared to controller and other specs

Initial Comment:
I've always found it odd that helpers called directly in the it() block, and not through an instance of some sort, eg typing

it "should do stuff" do
  helper_method.should == "output"
end

and even worse

it "should do stuff" do
  mock(:helper_method).and_return("thingies")
  #..
end

eg its not obvious at first sight exactly what you're mocking/expecting on, and its very inconsistant to general (non-rails) specs and controller/model specifications, where operate on some object.

Why not mix the helper into a dummy Helper object instead? So we can do:

it "should do stuff" do
  helper.mock(:helper_method).and_return("thingies")
  helper.other_method.should == "thingies are good"
end


----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 23:26

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/65-13741-helper-specs-oddities-compared-to-controller-and-other-specs#ticket-65-2

----------------------------------------------------------------------

Comment By: Johan S?rensen (johansorensen)
Date: 2007-09-07 05:50

Message:
I think (or guess we'd have to as you say) supporting both, and recommending 
the helper.foo approach where it's possible (docs, examples), and then 
deprecating/removing the existing approach whenever it's appropriate (1.5/2.0)

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-09-07 05:40

Message:
That's a great idea, but a year late.

We could offer up a helper object as an alternative, but I wouldn't want to break any existing helper specs in the process. The only problem there is that it becomes confusing when you're allowed to write things in both ways and then someone else comes in contact with the specs and sees
it "should do stuff" do
  helper.mock(:helper_method).and_return("thingies")
  other_method.should == "thingies are good"
end

WDYT?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13741&group_id=797

From noreply at rubyforge.org  Sun Nov 18 23:27:23 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 23:27:23 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-13759 ] rails_rspec overwrites test
	mappings added in .autotest
Message-ID: <20071119042723.4CAB2185859A@rubyforge.org>

Bugs item #13759, was opened at 2007-09-07 15:12
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13759&group_id=797

Category: Autotest
Group: v1.0 (example)
Status: Open
Resolution: None
Priority: 3
Submitted By: Geoffrey Wiseman (diathesis)
Assigned to: Nobody (None)
Summary: rails_rspec overwrites test mappings added in .autotest

Initial Comment:
If you add any any test mappings to .autotest, rails_rspec seems to trample these; that means any added directories (e.g. spec/acceptance) have to be added in rails_rspec, currently.

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 23:27

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/66-13759-rails_rspec-overwrites-test-mappings-added-in-autotest#ticket-66-2

----------------------------------------------------------------------

Comment By: Geoffrey Wiseman (diathesis)
Date: 2007-09-17 18:30

Message:
This is the bit I used:
module Autotest::AdditionalSpecs
  Autotest.add_hook :initialize do |at|
    at.test_mappings[ %r%^spec/acceptance/.*rb$% ] = proc do
|filename|
       return filename
    end
    
    puts "Mappings @ .autotest:"
    at.test_mappings.each do |k,v|
      puts "  #{k} => #{v}"
    end
  end
end

When I ran this, I could see it being added in .autotest,
but then when rails_rspec.rb ran, if I printed them out in
there, it would show that it had overwritten the original
values (as of the version i'm on, anyway).

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-09-16 04:04

Message:
Disregard that last message - wrong ticket.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-09-16 04:02

Message:
I added the failing example to r2566 (set to pending). We got rid of the matcher when we added a default set of predicate matchers that included exist. We only added that to the ExampleApi, so we'd need to move the whole predicate matchers bit over to Spec::Matchers to get it to work. This is now on the radar but not first priority. If you can figure out how to do that, feel free to submit another patch. Otherwise, we'll get to it eventually.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-09-13 02:16

Message:
Please post your .autotest file so I can see this in action.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13759&group_id=797

From noreply at rubyforge.org  Sun Nov 18 23:27:48 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 23:27:48 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-13829 ] TextMate bundle does not map
	classes in /lib in a rails app to /spec/lib
Message-ID: <20071119042748.B402D1858598@rubyforge.org>

Bugs item #13829, was opened at 2007-09-10 22:56
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13829&group_id=797

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Nobody (None)
Summary: TextMate bundle does not map classes in /lib in a rails app to /spec/lib

Initial Comment:
In non-rails apps, the TextMate bundle maps files in /lib to files in /spec. 

Because Rails doesn't put lib under /app (it puts it in the project root), the TextMate bundle expects the specs for classes in /lib to be directly under /spec. RSpec users, however, like to put specs for classes in /lib in /spec/lib. So we need to make the mapping smarter so it knows if it's in a Rails app, and if so correctly maps /lib to /spec/lib.

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 23:27

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/67-13829-textmate-bundle-does-not-map-classes-in-lib-in-a-rails-app-to-spec-lib

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13829&group_id=797

From noreply at rubyforge.org  Sun Nov 18 23:30:37 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 23:30:37 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-13830 ] TextMate bundle runs examples
	twice and outputs the command line output as well
Message-ID: <20071119043037.C8316185859A@rubyforge.org>

Bugs item #13830, was opened at 2007-09-10 23:03
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13830&group_id=797

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Nobody (None)
Summary: TextMate bundle runs examples twice and outputs the command line output as well

Initial Comment:
Trunk rev2559:

Now that we've enabled unified spec and test runs, we have some cleanup to do.

Open up any foo_spec.rb file and run the file using CMD-R. The output shows what looks like a bunch of Test::Unit output:

Loaded suite /tmp/temp_textmate.g66g4G Started

followed by a second listing of all of the examples that were run, followed by the normal command line output:

Finished in 0.00704 seconds. 0 tests, 0 assertions, 0 failures, 0 errors Finished in 0.00123 seconds 0 examples, 0 failures

See the attached screenshot.

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 23:30

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/68-13830-textmate-bundle-runs-examples-twice-and-outputs-the-command-line-output-as-well#ticket-68-1

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13830&group_id=797

From noreply at rubyforge.org  Sun Nov 18 23:31:43 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 23:31:43 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-13879 ] "P" for pending looks too much
	like "F" for failure -- please put back "*"
Message-ID: <20071119043143.BF5BD1858598@rubyforge.org>

Bugs item #13879, was opened at 2007-09-12 15:42
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13879&group_id=797

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Alex Chaffee (alexch)
Assigned to: Nobody (None)
Summary: "P" for pending looks too much like "F" for failure -- please put back "*"

Initial Comment:
We love pending! But we hate "P". From across the room, or for eyes over 40 years old, it looks like our test run just broke when actually it's just a pending test. Why did you change it from "*"? We like "*". It even means "footnote" or "see below for more information" which is actually pretty appropriate for a pending example...


----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 23:31

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/69-13879-p-for-pending-looks-too-much-like-f-for-failure-please-put-back#ticket-69-2

----------------------------------------------------------------------

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-09-13 19:40

Message:
Don't you run with --color?  I'm sure that would be even easier on the eyes.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13879&group_id=797

From noreply at rubyforge.org  Sun Nov 18 23:32:52 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 23:32:52 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-14406 ] rake spec:plugins:rspec_on_rails
	fails with Rails 2.0 preview release
Message-ID: <20071119043252.9E64C1858598@rubyforge.org>

Bugs item #14406, was opened at 2007-10-03 06:30
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=14406&group_id=797

Category: rails plugin
Group: None
Status: Open
Resolution: Accepted
Priority: 3
Submitted By: Neil Wilson (aldursys)
Assigned to: David Chelimsky (dchelimsky)
Summary: rake spec:plugins:rspec_on_rails fails with Rails 2.0 preview release

Initial Comment:
File helper_spec_spec.rb still contains ActionView::Helpers::JavascriptMacrosHelper and ActionView::Helpers::PaginationHelper. 

Once you comment these out (which I'm sure isn't the correct fix), then you get failures due to a lack of fixtures.

Is it worth removing this task in Rake until you get the specs working?



----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 23:32

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/70-14406-rake-spec-plugins-rspec_on_rails-fails-with-rails-2-0-preview-release#ticket-70-2

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-31 08:39

Message:
OK - I've really resolved the first problem (trying to load helpers that don't exist). I had gotten it to work in rspec's pre_commit process based on env vars that get set during that process. Obviously that doesn't help when another app is using the plugin.

The problem of fixtures remains, but I see the path. Should have this fixed soon.

----------------------------------------------------------------------

Comment By: Neil Wilson (aldursys)
Date: 2007-10-03 14:09

Message:
r2691 still can't find the fixtures specified in 
helper_spec_spec.rb when the Rake task is run from an 
arbitrary Rails app.




----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-03 10:56

Message:
Forgot to close this.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-03 10:04

Message:
Absolutely not. Better to fix the problem than hide it, don't you think.

Resolved in r2691, which now passes against rails 1.2.1, 1.2.2, 1.2.3, 2.0.0 preview, and edge

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=14406&group_id=797

From noreply at rubyforge.org  Sun Nov 18 23:34:12 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 23:34:12 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-14475 ] Tempfile doesn't pass
	be_an_instance_of(Tempfile). Maybe becouse it use decorator
Message-ID: <20071119043412.7B1A81858598@rubyforge.org>

Bugs item #14475, was opened at 2007-10-05 06:40
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=14475&group_id=797

Category: expectation module
Group: v1.0 (example)
Status: Open
Resolution: None
Priority: 3
Submitted By: Serhiy Boiko (cris)
Assigned to: David Chelimsky (dchelimsky)
Summary: Tempfile doesn't pass be_an_instance_of(Tempfile). Maybe becouse it use decorator

Initial Comment:
describe "My problem" do

  it "should pass be_an_instance_of for newly created Tempfile" do
    # create test object
    xml_tempfile = Tempfile.new "object.xml"
    xml_tempfile.close
    # this kind of test passed normally
    xml_tempfile.class.should eql(Tempfile)
    # this doesn't pass
    xml_tempfile.should be_an_instance_of(Tempfile)
  end
end

In ruby-debug I found, that in validation stage, object become instance of File. Maybe something unwrap Delegator in Tempfile?

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 23:34

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/71-14475-tempfile-doesn-t-pass-be_an_instance_of-tempfile-maybe-becouse-it-use-decorator#ticket-71-2

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-05 09:56

Message:
It works - but you shouldn't have to switch the requires. I'd say its still a bug.

----------------------------------------------------------------------

Comment By: Serhiy Boiko (cris)
Date: 2007-10-05 09:51

Message:
Thanks a lot.
Its work.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-05 07:53

Message:
This is related to http://rubyforge.org/tracker/index.php?func=detail&aid=11526&group_id=797&atid=3149.

Check this out - if you require in this order:

require 'spec'
require 'tempfile'

Then your example fails. However, if you require in this order:

require 'tempfile'
require 'spec'

Then the example passes!




----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=14475&group_id=797

From noreply at rubyforge.org  Sun Nov 18 23:35:33 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 23:35:33 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15244 ] spec --heckle command does not
	return error code to shell if heckling fails
Message-ID: <20071119043533.351FD1858598@rubyforge.org>

Bugs item #15244, was opened at 2007-10-31 16:44
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=15244&group_id=797

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Ashley Moran (ashleymoran)
Assigned to: Nobody (None)
Summary: spec --heckle command does not return error code to shell if heckling fails

Initial Comment:
rev 2804

spec --heckle returns 0 in all cases, even when heckling flags unspecced code




----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 23:35

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/72-15244-spec-heckle-command-does-not-return-error-code-to-shell-if-heckling-fails

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=15244&group_id=797

From noreply at rubyforge.org  Sun Nov 18 23:35:57 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 23:35:57 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15245 ] spec --heckle runs heckle even
	when there are initially failing specs fails
Message-ID: <20071119043557.83EBC1858598@rubyforge.org>

Bugs item #15245, was opened at 2007-10-31 16:45
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=15245&group_id=797

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Ashley Moran (ashleymoran)
Assigned to: Nobody (None)
Summary: spec --heckle runs heckle even when there are initially failing specs fails

Initial Comment:
rev 2804


----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 23:35

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/72-15244-spec-heckle-command-does-not-return-error-code-to-shell-if-heckling-fails

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=15245&group_id=797

From noreply at rubyforge.org  Sun Nov 18 23:36:49 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 23:36:49 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15248 ] Typo in spec --help
Message-ID: <20071119043649.DECBE1858598@rubyforge.org>

Bugs item #15248, was opened at 2007-10-31 17:48
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=15248&group_id=797

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Ashley Moran (ashleymoran)
Assigned to: Nobody (None)
Summary: Typo in spec --help

Initial Comment:
-l, --line LINE_NUMBER           Execute behaviout

Aren't you glad there are pedants like me around :)

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 23:36

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/73-15248-typo-in-spec-help

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=15248&group_id=797

From noreply at rubyforge.org  Sun Nov 18 23:38:02 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 23:38:02 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15255 ] Views generated incorrectly from
	script/generate rspec_controller when using modules
Message-ID: <20071119043802.B24811858598@rubyforge.org>

Bugs item #15255, was opened at 2007-11-01 07: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.

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 23:38

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/74-15255-views-generated-incorrectly-from-script-generate-rspec_controller-when-using-modules

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=15255&group_id=797

From noreply at rubyforge.org  Sun Nov 18 23:38:56 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 23:38:56 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15364 ] if all examples are pending,
	exceptions in 'before' block are not shown
Message-ID: <20071119043856.EBD5F185859A@rubyforge.org>

Bugs item #15364, was opened at 2007-11-05 15: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 Humphries (spicycode)
Date: 2007-11-18 23:38

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/75-15364-if-all-examples-are-pending-exceptions-in-before-block-are-not-shown#ticket-75-2

----------------------------------------------------------------------

Comment By: Chad Woolley (thewoolleyman)
Date: 2007-11-06 10: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 09: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  Sun Nov 18 23:39:22 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 23:39:22 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15372 ] spec command with no args
	doesn't output anything
Message-ID: <20071119043922.E19FF185859A@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)

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 23:39

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/76-15372-spec-command-with-no-args-doesn-t-output-anything

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=15372&group_id=797

From noreply at rubyforge.org  Sun Nov 18 23:41:08 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 23:41:08 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15544 ] Interdependency among specs
Message-ID: <20071119044108.5E75D1858598@rubyforge.org>

Bugs item #15544, was opened at 2007-11-11 03:08
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=15544&group_id=797

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: David Chelimsky (dchelimsky)
Summary: Interdependency among specs

Initial Comment:

2 sets of interdependency among the specs in trunk/spec, @ revision 2848:

1. Two failures occur when running autotest (or with ruby bin/spec spec/spec/mocks/** in trunk/spec):

1)
Spec::Mocks::MockExpectationError in 'calling :should_receive with an options hash should report the file and line submitted with :expected_from'
Mock 'Spec::Runner::Reporter' expected :example_finished with (any args) once, but received it 0 times
./spec/spec/mocks/options_hash_spec.rb:21:

2)
Spec::Mocks::MockExpectationError in 'calling :should_receive with an options hash should use the message supplied with :message'
Mock 'Spec::Runner::Reporter' expected :example_finished with (any args) once, but received it 0 times
./spec/spec/mocks/options_hash_spec.rb:35:

I haven't really investigated this part of the framework - so I'll leave it up to you guys.



2. the second one can be reproduced by running the following (inside of trunk/spec):

escher: ruby bin/spec spec/spec/dsl/example_class_definition_spec.rb --reverse
F.....

1)
'Spec::DSL::ExampleClassDefinitionSpec should run' FAILED
expected true, got nil
./spec/spec/dsl/example_class_definition_spec.rb:44:

Finished in 0.00325 seconds

6 examples, 1 failure

But running them normally gives good results:

escher: ruby bin/spec spec/spec/dsl/example_class_definition_spec.rb   
......

Finished in 0.002986 seconds

6 examples, 0 failures


This second example is rather 'nitpicky' - disregard it if you don't think it's important.

Scott


BTW: I'm running on OS X.4, ruby 1.8.6 patchlevel-110, and trunk @rev 2848


----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 23:41

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/77

----------------------------------------------------------------------

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-11-11 16:39

Message:
The second one occurs because the specs look like this:


module MyMod
  class SomeClass
    
    it "should run this spec" do
      run_this = true
    end
  end
  
  describe "SomeClass" do
    it "should run the spec" do
      run_this.should be_true
    end
  end
end

When the specs are run (forward), run_this gets set to true,
and the second spec passes.  When run backwards, run_this
only gets set to true in the second spec, failing the first one.

Obviously I haven't presented the details of this right -
the variable is well scoped (meaning it won't go out of
scope as it would in this example).

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-11 08:37

Message:
Got options_hash_spec working with or without --reverse. Don't understand the dependency yet.

Also still need to figure out the 2nd one.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=15544&group_id=797

From noreply at rubyforge.org  Sun Nov 18 23:42:28 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 23:42:28 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15604 ] Cannot use console colouring
	mode without &quot; win32console&quot; gem on Windows.
Message-ID: <20071119044228.687911858598@rubyforge.org>

Bugs item #15604, was opened at 2007-11-13 07:50
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=15604&group_id=797

Category: runner module
Group: None
Status: Open
Resolution: Accepted
Priority: 3
Submitted By: Roman Chernyatchik (romeo)
Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: Cannot use console colouring mode without &quot;win32console&quot; gem on Windows.

Initial Comment:
Cannot use console colouring mode without "win32console" gem on Windows.

Hi guys! I've written renderer for rspec colouring output, but I cannot use it on Windows platform. Please add opportunity to use colouring mode on Windows without "win32console" gem!

The problem is in base_text_formatter.rb: 

def colour=(colour)
     @colour = colour
     begin ; require 'Win32/Console/ANSI' if @colour && PLATFORM =~ /win32/ ; rescue LoadError ;  raise "You must gem install win32console to use colour on Windows" ; end
end 

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 23:42

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/78-15604-cannot-use-console-colouring-mode-without-win32console-gem-on-windows#ticket-78-2

----------------------------------------------------------------------

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-11-14 19:14

Message:
So what's your suggestion for coloured console output without the win32console gem?

Would it help if you could give --colour an argument like:

--colour MyColourer

where MyColourer is some alternative (your?) implementation of colouring?

Can you submit a patch? (I'm reopening this now that I think I understand what you mean)

----------------------------------------------------------------------

Comment By: Roman Chernyatchik (romeo)
Date: 2007-11-14 11:37

Message:
We've implemented  colour support in console panel of ROR plugin for IntelliJ 
IDEA.  But "win32console" gem doesn't allow us to redirect output stream thus it 
hides all output from our console even when colour mode is disabled. 

----------------------------------------------------------------------

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-11-13 11:26

Message:
This makes no sense. You must install the gem to have console colour on windows. The error message even tells you that.

Or tell us how to have colour support without the gem - I don't think it's possible.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=15604&group_id=797

From noreply at rubyforge.org  Sun Nov 18 23:43:43 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 23:43:43 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15638 ] When naming a protected method,
	if it begins with 'should_' it causes it to be treated as an
	example.
Message-ID: <20071119044343.4F43F1858598@rubyforge.org>

Bugs item #15638, was opened at 2007-11-15 02:32
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=15638&group_id=797

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Nathan Sutton (fowlduck)
Assigned to: Nobody (None)
Summary: When naming a protected method, if it begins with 'should_' it causes it to be treated as an example.

Initial Comment:
starting a protected method with should_ causes it to be treated as an example.

edge rails revision: 8146
edge rspec revision: 2889
edge rspec_on_rails revision: 2889

describe SessionsController do

  # a bunch of examples, some that call should_be_logged_in

protected

  def should_be_logged_in
    response.session.should_not be_nil
    session[:user].should_not be_nil
  end

end

When running the spec:

SessionsController should_be_logged_in' FAILED
expected not nil, got nil
./spec/controllers/sessions_controller_spec.rb:111:in `should_be_logged_in'
script/spec:4:


Renamed the method to 'be_logged_in' and all specs then pass.  Line 111, in this case, is 'session[:user].should_not be_nil'.



----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 23:43

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/79-15638-when-naming-a-protected-method-if-it-begins-with-should_-it-causes-it-to-be-treated-as-an-example#ticket-79-2

----------------------------------------------------------------------

Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 15:32

Message:
We have it, shared behaviors, it just doesn't take parameters.  If it did, and 
maybe even a proc, you could do a LOT.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-15 15:17

Message:
Nathan: I agree - there should be a better API for helper methods and sharing. We likely won't get there for this release, but it is on the radar.

----------------------------------------------------------------------

Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 15:17

Message:
In my case, I was using a protected method to do "should_be_logged_in", which 
just does a couple expectations.  RSpec was interpreting it as a spec and 
running it as one, which of course made it fail.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-15 15:16

Message:
Scott - nobody is using it yet because nobody really knows about it yet - it's all in trunk and experimental - but is the result of several conversations I had w/ RubyConf attendees.

----------------------------------------------------------------------

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-11-15 15:14

Message:
I don't quite understand this thread.  Who is actually using should_... ?

I know some people are using test "here is a description of something to test", and some people are using should "do something or other", but who is using should_do_something_or_other?



----------------------------------------------------------------------

Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 15:02

Message:
Well, I'm using methods starting with should to group examples for a specific 
purpose.  If there was a way to do this and re-use them then I wouldn't be doing 
this in the first place.  I would use shared behaviors but you can't pass values 
into them.  Maybe the solution is not to remove this, but to define a way to 
accomplish what I was trying to do, one that won't get stomped on.


----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-15 14:57

Message:
It's not only a matter of a pit-stop. It's that some people would prefer to stay in class/method land and use this format from day one and keep it that way:

class FooSpec < Spec::ExampleGroup
  def should_bar
    ...
  end
end

My opinion is that this is a reasonable request and that there's no reason not to offer it - except for this conflict with helpers that start w/ should.

You can't start helpers with test in test unit, I don't see why this should be a big deal.

----------------------------------------------------------------------

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-11-15 14:50

Message:
I think we should kill the feature. test_ methods and it blocks is enough. I don't think we need another pit stop in between.

----------------------------------------------------------------------

Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 11:51

Message:
This is the cause of bug #15637 and the subtlety of it will cause breakage for 
those who don't expect it.  How long did we spend trying to figure this out?

----------------------------------------------------------------------

Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 11:39

Message:
Maybe not kill it, but make it a configuration option?  Also, I think this is the 
reason that my specs were failing last night concerning the inclusion of the 
module, bug #15637.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-15 09:58

Message:
I'd sooner kill the feature. That sort of subtlety would make things very confusing.

In my view, the feature is either in or out.

Thoughts?

----------------------------------------------------------------------

Comment By: Nathan Sutton (fowlduck)
Date: 2007-11-15 02:46

Message:
Would it be possible to only do this for public methods, and exclude protected 
ones?

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-15 02:44

Message:
That's actually by design. In an effort to play well with others, we're working towards a world in which people who prefer to use classes and methods can do this:

class FooSpec < Spec::ExampleGroup
  def should_bar
    ...
  end
end

This works just like Test::Unit except it looks for methods that start with "should" instead of "test". This means that you can not have helper methods that start with "should".

I'm going to leave this ticket open and would welcome opinions on this.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=15638&group_id=797

From noreply at rubyforge.org  Sun Nov 18 23:45:07 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 23:45:07 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15670 ] Win32 + autotest --colour +
	script/rspec + win32console == NO OUTPUT
Message-ID: <20071119044507.C38621858598@rubyforge.org>

Bugs item #15670, was opened at 2007-11-16 02:02
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=15670&group_id=797

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Will Green (hotgazpacho)
Assigned to: Nobody (None)
Summary: Win32 + autotest --colour + script/rspec + win32console == NO OUTPUT

Initial Comment:
* Windows Vista Home Premium, 32 bit
* Ruby 1.8.6 (2007-03-13 patchlevel 0) [i386-mswin32] (One-Click 186-25)
* Rails 1.2.5
* rspec plugin 1.0.8 (tags/CURRENT) (also have Gem RSpec, 1.0.8)
* rspc_on_rails plugin 1.0.8 (tags/CURRENT)
* Win32Console 1.0.8
* ZenTest 3.6.1

spec/spec.opts:
--colour
--format
progress
--loadby
mtime
--reverse

>From the root of my Rails app:

> autotest
loading autotest/rails_rspec
C:\ruby\bin\ruby.exe -S script/spec -O spec/spec.opts spec/models/membership_application_spec.rb

>>> no output

> spec -O spec/spec.opts spec/models/membership_application_spec.rb
............

Finished in 1.317 seconds

12 examples, 0 failures

>>> The line of dots and the "12 examples..." are both in green.

Something about script/spec is causing all output to be lost.

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 23:45

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/80-15670-win32-autotest-colour-script-rspec-win32console-no-output#ticket-80-2

----------------------------------------------------------------------

Comment By: Will Green (hotgazpacho)
Date: 2007-11-16 02:28

Message:
Updated to trunk on both rspec and rspec_on_rails plugins.
Still no output with --colour in spec/spec.opts.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-11-16 02:12

Message:
Will - thanks for the report - but 1.0.8 is quite old by now :).

Since none of us on the dev team have vista, would you do us a favor and install the rspec's trunk and let us know if you still have this problem?

----------------------------------------------------------------------

Comment By: Will Green (hotgazpacho)
Date: 2007-11-16 02:04

Message:
If I remove --colour from spec/spec.opts, then  I get
output, but it is NOT colored.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=15670&group_id=797

From noreply at rubyforge.org  Sun Nov 18 23:45:42 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 23:45:42 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-15719 ] when a method is stubbed and
	then mocked, error message is misleading
Message-ID: <20071119044542.39DCF1858598@rubyforge.org>

Bugs item #15719, was opened at 2007-11-18 12:36
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=15719&group_id=797

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Nobody (None)
Summary: when a method is stubbed and then mocked, error message is misleading

Initial Comment:
module Spec
  module Mocks
    describe "mock failure when the mock receives the right message with the wrong args" do
      it "should tell you when it receives the right message with the wrong args" do
        m = mock("foo")
        m.should_receive(:bar).with("message")
        lambda {
          m.bar("different message")
        }.should raise_error(Spec::Mocks::MockExpectationError, %Q{Mock 'foo' expected :bar with ("message") but received it with ("different message")})
        m.bar("message") # allows the spec to pass
      end

      it "should tell you when it receives the right message with the wrong args if you stub the method" do
        pending("fix bug") do
          m = mock("foo")
          m.stub!(:bar)
          m.should_receive(:bar).with("message")
          lambda {
            m.bar("different message")
          }.should raise_error(Spec::Mocks::MockExpectationError, %Q{Mock 'foo' expected :bar with ("message") but received it with ("different message")})
          m.bar("message") # allows the spec to pass
        end
      end
    end
  end
end

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 23:45

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/81-15719-when-a-method-is-stubbed-and-then-mocked-error-message-is-misleading

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=15719&group_id=797

From noreply at rubyforge.org  Sun Nov 18 23:48:34 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 23:48:34 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-10681 ] Documentation for
	should have_rjs
Message-ID: <20071119044834.CACB91858598@rubyforge.org>

Feature Requests item #10681, was opened at 2007-05-08 00:03
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10681&group_id=797

Category: rails plugin
Group: None
Status: Open
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: Documentation for should have_rjs

Initial Comment:
I could not figure out how to use it and got unexplainable exceptions.
A simple example would be great.

I will post the exception later.

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 23:48

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/82-10681-documentation-for-should-have_rjs#ticket-82-2

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-05-08 00:55

Message:
have_rjs wraps assert_select_rjs. We should improve our docs if you're having trouble understanding, but in the mean time you can take a look at http://api.rubyonrails.com/classes/ActionController/Assertions/SelectorAssertions.html#M000209 and you might find your answer there.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10681&group_id=797

From noreply at rubyforge.org  Sun Nov 18 23:49:08 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 23:49:08 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-10695 ] Add fixtures method
	in shared specs
Message-ID: <20071119044908.BDB011858598@rubyforge.org>

Feature Requests item #10695, was opened at 2007-05-08 14:46
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10695&group_id=797

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: Add fixtures method in shared specs

Initial Comment:
Something like this:

describe "comment/_new_comment", :shared => true, :behaviour_type => "view" do
  fixtures :patent_applications
end

describe "comment/_new_comment", "logged in" do
  it_should_behave_like "comment/_new_comment"
end


----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 23:49

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/83-10695-add-fixtures-method-in-shared-specs

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10695&group_id=797

From noreply at rubyforge.org  Sun Nov 18 23:50:15 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 23:50:15 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-10696 ] before(:all) and
	after(:all) should be instance_evaled in the EvalModule object
Message-ID: <20071119045015.4A9D21858598@rubyforge.org>

Feature Requests item #10696, was opened at 2007-05-08 14:53
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10696&group_id=797

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: before(:all) and after(:all) should be instance_evaled in the EvalModule object

Initial Comment:
This would allow methods such as 'fixtures' to be called in before(:all)

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 23:50

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/84-10696-before-all-and-after-all-should-be-instance_evaled-in-the-evalmodule-object

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10696&group_id=797

From noreply at rubyforge.org  Sun Nov 18 23:51:22 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 23:51:22 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-11818 ] Have mode for Rails
	Error Handling
Message-ID: <20071119045122.5A20D1858598@rubyforge.org>

Feature Requests item #11818, was opened at 2007-06-25 02:13
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11818&group_id=797

Category: rails plugin
Group: None
Status: Open
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: Have mode for Rails Error Handling

Initial Comment:
Currently we default to raise an error as it happens.

There should be a way to use Rail's default error handling. This is needed to verify that error specific behaviour is occurring, such as exception notification.

To start things off, I added ActionController::Rescue#use_rails_error_handling! and ActionController::Rescue#use_rails_error_handling? to do this (Rev 2128).

Thoughts?

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 23:51

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/85-11818-have-mode-for-rails-error-handling#ticket-85-2

----------------------------------------------------------------------

Comment By: Brian Takita (btakita)
Date: 2007-08-08 00:55

Message:
That looks good to me.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-06-25 02:22

Message:
Well - maybe the exclamation point doesn't make sense except when the method is being called directly on ActionController::Rescue. But I think we should either always have the exclamation point or never. Otherwise it'll just get confusing.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-06-25 02:20

Message:
Seems reasonable. I think that same method should then be made available via config:

Spec::Runner.configure do |config|
  config.use_rails_error_handling!
end

or directly in a given behaviour:

describe SomeController do
  use_rails_error_handling!
  ...
end

WDYT?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11818&group_id=797

From noreply at rubyforge.org  Sun Nov 18 23:54:15 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 23:54:15 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-10699 ] Shared Behaviour
	error message should include the Behaviour that is using it
Message-ID: <20071119045415.CAE811858598@rubyforge.org>

Feature Requests item #10699, was opened at 2007-05-08 16:00
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10699&group_id=797

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: Shared Behaviour error message should include the Behaviour that is using it

Initial Comment:
describe "shared" do
  it "fails" do
    fail
  end
end

describe "consumer" do
  it_should_behave_like "shared"
end

Here is the error message:
'shared fails' FAILED

Is would be useful if it where something like:
'consumer - shared fails' FAILED


----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 23:54

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/86-10699-shared-behaviour-error-message-should-include-the-behaviour-that-is-using-it

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10699&group_id=797

From noreply at rubyforge.org  Sun Nov 18 23:55:19 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 23:55:19 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-10718 ] Add :locals hash to
	'it_should_behave_like' method (SharedBehavior)
Message-ID: <20071119045519.6D54E1858598@rubyforge.org>

Feature Requests item #10718, was opened at 2007-05-09 10:36
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10718&group_id=797

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Chris Hoffman (hoffman_c)
Assigned to: Nobody (None)
Summary: Add :locals hash to 'it_should_behave_like' method (SharedBehavior)

Initial Comment:
It would be great if we could pass arbitrary variables into the shared behavior specs, for things such as differing controller actions.  Right now, I'm having to do the following:

before(:all) do
   @action = "foo"
end
it_should_behave_like "CRUD"

Instead, I could imagine something like the following, a la partial locals:

it_should_behave_like "CRUD", :locals => { :action => "foo" }

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 23:55

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/87-10718-add-locals-hash-to-it_should_behave_like-method-sharedbehavior#ticket-87-2

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-05-16 00:03

Message:
It happens implicitly. Calling #it_should_behave_like copies all the exampls from the shared behaviour into the current behaviour. Any local variables defined before(:each) example are available in each example.

----------------------------------------------------------------------

Comment By: Chris Hoffman (hoffman_c)
Date: 2007-05-09 11:19

Message:
how would @thing be assigned in the call to
it_should_behave_like in your example?  

I was imagining that a local 'thing' variable would get
assigned, perhaps with block locals.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-05-09 11:10

Message:
Interesting idea but there's a disconnect. Locals are actually slung over to another scope (the partial), whereas shared examples are all executed in the same scope as any non-shared examples. It's, conceptually, a different animal, that will surely lead to confusion when you start doing this:

describe Thing do
  before(:each) do
    @thing = Thing.new(:some_state)
  end
  
  it_should_behave_like "other things", :locals => { :thing => Thing.new(:some_other_state) }
  
  it "should do something unique" do
    @thing.should write_novels
  end
end

In this case, both assignments to @thing happen in the same context, so the last one executed wins. I, personally, would rather not have to debug that scenario.

Other thoughts?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10718&group_id=797

From noreply at rubyforge.org  Sun Nov 18 23:56:08 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 23:56:08 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-10775 ] Allow fixtures to be
	specified in config with finer granularity
Message-ID: <20071119045608.6D7EC1858598@rubyforge.org>

Feature Requests item #10775, was opened at 2007-05-11 08:30
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10775&group_id=797

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Nobody (None)
Summary: Allow fixtures to be specified in config with finer granularity

Initial Comment:
Similar to http://rubyforge.org/tracker/index.php?func=detail&aid=10770&group_id=797&atid=3152, let's support this:

Spec::Runner.configure do |config|
  config.global_fixtures(:fixture1, :fixture2, :behaviour_type => :model)
end



----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 23:56

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/88-10775-allow-fixtures-to-be-specified-in-config-with-finer-granularity

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10775&group_id=797

From noreply at rubyforge.org  Sun Nov 18 23:57:19 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 23:57:19 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-10814 ] Runner loads shared
	code, test cases require them again
Message-ID: <20071119045719.8C3BC1858598@rubyforge.org>

Feature Requests item #10814, was opened at 2007-05-13 19:03
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10814&group_id=797

Category: runner / command line
Group: None
Status: Open
Priority: 3
Submitted By: Assaf Arkin (assaf)
Assigned to: David Chelimsky (dchelimsky)
Summary: Runner loads shared code, test cases require them again

Initial Comment:
Our test directory contains one file that provides methods and behaviores shared by all other test files. To run individual files, each one requires that shared file. 

However, when running spec test, RSpec loads all the files from the test directory (and its sub-directories). So the file gets loaded once (by RSpec) and required once (by the test files), and interpreted twice (by Ruby). Some of the code doesn't like that.

The current workaround is to detect the second load and ignore it (e.g. unless defined?(SomeConst)). But given the amount of time it took to find the culprit and work around it, can RSpec require the file instead, or allow a directory of shared behaviors not loaded by default?

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 23:57

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/89-10814-runner-loads-shared-code-test-cases-require-them-again#ticket-89-2

----------------------------------------------------------------------

Comment By: Assaf Arkin (assaf)
Date: 2007-06-06 00:22

Message:
require is essentially load but it checks against
$LOADED_FEATURES, so you can always remove those entries
from $LOADED_FEATURES (or just keep a before copy and
replace it) in order to load the same test files again.

This wouldn't work for my test cases in DRb, but will work
for them on the command line.

In my opinion a long term solution can't assume that the
Ruby environment returns to pristine condition, and will
fork a new process each time the tests are run.


----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-06-05 18:16

Message:
Unfortunately, I'm going to have to revert this - this fix broke drb. We'll have to find a different solution.

----------------------------------------------------------------------

Comment By: Patrick Ritchie (pritchie)
Date: 2007-06-05 18:00

Message:
Reason: load is required for spec_server (drb) to work correctly. 

If we use require the behaviours only get checked on the first run of a given spec file. On subsequent runs we get the behaviours don't get loaded causing this problem:

http://rubyforge.org/pipermail/rspec-users/2007-May/001633.html



----------------------------------------------------------------------

Comment By: Assaf Arkin (assaf)
Date: 2007-05-16 01:00

Message:
Thanks!

Assaf

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-05-15 23:35

Message:
No reason. Fixed in r1958.

----------------------------------------------------------------------

Comment By: Assaf Arkin (assaf)
Date: 2007-05-15 22:21

Message:
More pain than it's worth. I'm going to have to explain to
every developer how to properly run the test cases, they're
of course not going to RTFM, so their first attempt will
fail miserably. And with each project deciding to exclude a
different file ...

Is there a particular reason for RSpec to use load instead
of require?

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-05-15 20:35

Message:
How about an "exclude" command line option?

spec spec --exclude spec/shared.rb

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10814&group_id=797

From noreply at rubyforge.org  Sun Nov 18 23:58:34 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 23:58:34 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-10823 ] separate errors and
	failures in output
Message-ID: <20071119045834.BB5C91858598@rubyforge.org>

Feature Requests item #10823, was opened at 2007-05-14 09:07
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10823&group_id=797

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Nobody (None)
Summary: separate errors and failures in output

Initial Comment:
Observe the following output:

=========================
$ spec user_spec.rb --format specdoc

User
- should be in any roles assigned to it (ERROR - 1)
- should NOT be in any roles not assigned to it (FAILED - 2)

1)
NameError in 'User should be in any roles assigned to it'
undefined local variable or method `user' for #<#<Class:0x14eca2c>:0x14ec6a8>
./user_spec.rb:6:

2)
'User should NOT be in any roles not assigned to it' FAILED
expected in_role?("unassigned role") to return false, got true
./user_spec.rb:12:

Finished in 0.017713 seconds

2 examples, 2 failures
=========================

The specdoc output makes a distinction between errors that are raised (ERROR - 1) and logical failures (FAILED - 2), but the last line of the output does not (2 examples, 2 failures).

The last line should make the distinction the same way the detailed output does:

2 examples, 1 failure, 1 error


----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 23:58

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/90-10823-separate-errors-and-failures-in-output#ticket-90-2

----------------------------------------------------------------------

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-07-10 14:44

Message:
Currently we only output the pending count when there are 1 or more pending. Failure count is always outputted, even when there are 0 (which is inconsistent with pending). How should we print out errors?

I think we should choose between one of the following:

a) Always print examples, only print errors/failures/pending inf > 0.

b) Always print all of them. This will probably make it a little easier for tools that wish to parse the output (like autotest)

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10823&group_id=797

From noreply at rubyforge.org  Sun Nov 18 23:59:23 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Nov 2007 23:59:23 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-10932 ] Documentation on
	upgrading the Rspec on Rails Plugin
Message-ID: <20071119045923.98B5F1858598@rubyforge.org>

Feature Requests item #10932, was opened at 2007-05-20 00:44
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10932&group_id=797

Category: rails plugin
Group: None
Status: Open
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: Documentation on upgrading the Rspec on Rails Plugin

Initial Comment:
Upgrading rpsec can be a pain.

There should be some procedues.

e.g.
svn mv Rename existing plugin
install latest version of plugin
remove renamed old version of plugin


----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 23:59

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/91-10932-documentation-on-upgrading-the-rspec-on-rails-plugin#ticket-91-2

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-06-01 06:44

Message:
Good point. I'll extend it.

----------------------------------------------------------------------

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-06-01 03:33

Message:
This won't work for people who checked it into svn - or people using svn:externals. It looks like these instructions will only work for people not using an scm at all(?)

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-05-31 19:40

Message:
Added this to docs in r2067

# from the root of your rails project
rm -rf vendor/plugins/rspec
rm -rf vendor/plugins/rspec_on_rails
ruby script/plugin install svn://rubyforge.org/var/svn/rspec/tags/CURRENT/rspec
ruby script/plugin install svn://rubyforge.org/var/svn/rspec/tags/CURRENT/rspec_on_rails
ruby script/generate rspec


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10932&group_id=797

From noreply at rubyforge.org  Mon Nov 19 00:00:50 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Nov 2007 00:00:50 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-10941 ] Example object
	should have a reference to its Description object
Message-ID: <20071119050051.0003B18585A3@rubyforge.org>

Feature Requests item #10941, was opened at 2007-05-20 15:06
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10941&group_id=797

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: Example object should have a reference to its Description object

Initial Comment:
This would assist in plugging in shared before(:each) and after(:each) callbacks.

For example Nathan Wilmes had an issue with setting a mock by default and only in certain Behaviour, he wanted to turn off mocks. One possible implementation would be:

describe "Storage Service Setup" do
  before(:each) do
    unless behaviour.real_storage_service?
      StorageService.stub!(:something)
    end
  end
end

describe Foo do
  real_storage_service
  it_should_behave_like "Storahge Service Setup"
end

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 00:00

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/92-10941-example-object-should-have-a-reference-to-its-description-object

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10941&group_id=797

From noreply at rubyforge.org  Mon Nov 19 00:01:22 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Nov 2007 00:01:22 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-10944 ] Use Pretty Print for
	Matching Errors
Message-ID: <20071119050123.1E1D318585B1@rubyforge.org>

Feature Requests item #10944, was opened at 2007-05-20 16:36
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10944&group_id=797

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: Use Pretty Print for Matching Errors

Initial Comment:
This would be useful for matching errors where printing the object results in a very long line.

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 00:01

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/93-10944-use-pretty-print-for-matching-errors

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10944&group_id=797

From noreply at rubyforge.org  Mon Nov 19 00:01:51 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Nov 2007 00:01:51 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-11093 ] Add a RSS on changes
	log in the public web site
Message-ID: <20071119050151.8F61218585B7@rubyforge.org>

Feature Requests item #11093, was opened at 2007-05-24 10:58
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11093&group_id=797

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Jean-Michel Garnier (garnierjm)
Assigned to: Nobody (None)
Summary: Add a RSS on changes log in the public web site

Initial Comment:
As the public web site seems to not contain a blog or RSS feed, I have used the excellent tool page2rss.com to generate a RSS feed on the http://rspec.rubyforge.org/changes.html  page.

To receive updates for this page in RSS format copy-paste http://page2rss.com/page/rss?url=rspec.rubyforge.org/changes.html into your feed reader. 

I have posted on my blog more details: http://21croissants.blogspot.com/2007/05/rspec-changes-log-rss.html

Maybe, this RSS link could be added in the web site?

On a sidenote, it would be great to be able see the site map of the documentation web site at the bottom of each page or in the header.

Apart from that, documentation content is great and style is quite cool, I am willing to contribute with more examples in the near future.

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 00:01

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/94-11093-add-a-rss-on-changes-log-in-the-public-web-site

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11093&group_id=797

From noreply at rubyforge.org  Mon Nov 19 00:02:29 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Nov 2007 00:02:29 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-11379 ] Add a Text Formatter
	that Show failures right away (as they come up)
Message-ID: <20071119050230.0CDCB18585B1@rubyforge.org>

Feature Requests item #11379, was opened at 2007-06-05 19:44
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11379&group_id=797

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: Add a Text Formatter that Show failures right away (as they come up)

Initial Comment:
This is useful for suites that take a long time to run (> 30 seconds).
The advantage is the developer can investigate the error right away instead of waiting for the suite run to finish.

This can be used in conjunction with the ProgressBarFormatter.

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 00:02

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/95-11379-add-a-text-formatter-that-show-failures-right-away-as-they-come-up

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11379&group_id=797

From noreply at rubyforge.org  Mon Nov 19 00:03:14 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Nov 2007 00:03:14 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-11707 ] paramters for shared
	behaviours
Message-ID: <20071119050314.2AAB818585A3@rubyforge.org>

Feature Requests item #11707, was opened at 2007-06-20 06:19
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11707&group_id=797

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: David Green (david_green)
Assigned to: Nobody (None)
Summary: paramters for shared behaviours

Initial Comment:
It would be useful if shared behaviours could accept parameters.

this thread on the rspec users mailing list is a good example of when such a feature is needed:

http://www.nabble.com/dynamic-specs-tf3927280.html

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 00:03

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/96-11707-paramters-for-shared-behaviours#ticket-96-2

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-06-20 07:35

Message:
Giving this some more thought, this turns out to be rather problematic. Not only due to the re-design work but because of usage problems. Let's say you have the following setup:

describe "All Accounts", :shared => true do |account|
  it "should let you withdraw less than it has" do
    account.deposit 50
    account.withdraw 20
    account.balance.should == 30
  end
  it "should not let you withdraw more than it has" do
    account.deposit 20
    account.withdraw 21
    account.balance.should == 20
  end
  ...
end

describe CheckingAccount do
  it_should_behave_like "All Accounts", CheckingAccount.new
  ...
end

This seems perfectly reasonable, right? Well the first problem is that the two examples in the shared behaviour don't have access to the account instance. You'd have to do this to your implementation:

describe "All Accounts", :shared => true do |acc|
  def account
    acc
  end
  ...
end

Once that problem is solved, we would find that the second example would fail saying the balance is 29. Why? Because CheckingAccount.new would only be evaluated once, and the same instance would be used in both of the examples.

We could solve by passing a block to it_should_behave_like:

describe CheckingAccount do
  it_should_behave_like "All Accounts" {CheckingAccount.new}
  ...
end

Or passing method names:

describe CheckingAccount do
  it_should_behave_like "All Accounts", :new_checking_account
  
  def new_checking_account
    CheckingAccount.new
  end
  ...
end

But now we're starting to loose the benefits to verbosity and confusion.

Anybody see a simpler way?


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11707&group_id=797

From noreply at rubyforge.org  Mon Nov 19 00:04:05 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Nov 2007 00:04:05 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-11818 ] Have mode for Rails
	Error Handling
Message-ID: <20071119050406.11CC318585A3@rubyforge.org>

Feature Requests item #11818, was opened at 2007-06-25 02:13
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11818&group_id=797

Category: rails plugin
Group: None
Status: Open
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: Have mode for Rails Error Handling

Initial Comment:
Currently we default to raise an error as it happens.

There should be a way to use Rail's default error handling. This is needed to verify that error specific behaviour is occurring, such as exception notification.

To start things off, I added ActionController::Rescue#use_rails_error_handling! and ActionController::Rescue#use_rails_error_handling? to do this (Rev 2128).

Thoughts?

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 00:04

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/97-11818-have-mode-for-rails-error-handling#ticket-97-2

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-18 23:51

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/85-11818-have-mode-for-rails-error-handling#ticket-85-2

----------------------------------------------------------------------

Comment By: Brian Takita (btakita)
Date: 2007-08-08 00:55

Message:
That looks good to me.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-06-25 02:22

Message:
Well - maybe the exclamation point doesn't make sense except when the method is being called directly on ActionController::Rescue. But I think we should either always have the exclamation point or never. Otherwise it'll just get confusing.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-06-25 02:20

Message:
Seems reasonable. I think that same method should then be made available via config:

Spec::Runner.configure do |config|
  config.use_rails_error_handling!
end

or directly in a given behaviour:

describe SomeController do
  use_rails_error_handling!
  ...
end

WDYT?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11818&group_id=797

From noreply at rubyforge.org  Mon Nov 19 00:05:07 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Nov 2007 00:05:07 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-11834 ] Fake Controller
	Flash object
Message-ID: <20071119050508.0630018585A3@rubyforge.org>

Feature Requests item #11834, was opened at 2007-06-25 13:06
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11834&group_id=797

Category: rails plugin
Group: None
Status: Open
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: Fake Controller Flash object

Initial Comment:
Currently it is difficult to test the values on Flash.now, because the Flash.sweep is called during the process action.

We made a Fake Flash Hash object that collects the flash content and does not sweep it when the request is processed.


----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 00:05

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/98-11834-fake-controller-flash-object#ticket-98-2

----------------------------------------------------------------------

Comment By: Brian Takita (btakita)
Date: 2007-06-27 02:38

Message:
Mainly, it was Nathan Wilmes who developed this. It is very
bare bones, and meant for primarily collecting value.

class MockFlashHash
  def initialize
    @hash = {}
    @now_hash = {}
  end

  def [](key)
    @hash[key]
  end

  def []=(key, obj)
    @hash[key] = obj
  end

  def discard(k = nil)
    initialize
  end

  def now
    @now_hash
  end

  def update(hash)
    @hash.update(hash)
  end

  def sweep
    # This is the key.  We don't really want flash.now's to
go away.
  end
end


----------------------------------------------------------------------

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-06-26 03:02

Message:
What does it look like?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11834&group_id=797

From noreply at rubyforge.org  Mon Nov 19 00:06:08 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Nov 2007 00:06:08 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-11916 ] View Specs should
	have all the View Helper modules included
Message-ID: <20071119050608.454CE18585A3@rubyforge.org>

Feature Requests item #11916, was opened at 2007-06-28 18:53
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11916&group_id=797

Category: rails plugin
Group: None
Status: Open
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: View Specs should have all the View Helper modules included

Initial Comment:
So we can call methods like h and truncate without resorting to view.send(:h) or 

class << view
  public :h
end
h()

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 00:06

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/99-11916-view-specs-should-have-all-the-view-helper-modules-included

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11916&group_id=797

From noreply at rubyforge.org  Mon Nov 19 00:08:13 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Nov 2007 00:08:13 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-11949 ] &amp; amp; quot;
	should_yield&amp; amp; quot; or &amp; amp; quot;
	.should raise_error(MySpecificError)&amp; amp; quot;
	equivalent for yields
Message-ID: <20071119050813.7139818585A3@rubyforge.org>

Feature Requests item #11949, was opened at 2007-07-01 20:49
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11949&group_id=797

Category: expectation module
Group: None
Status: Open
Priority: 3
Submitted By: S. Potter (mbbx6spp)
Assigned to: Nobody (None)
Summary: &amp;amp;quot;should_yield&amp;amp;quot; or &amp;amp;quot;.should raise_error(MySpecificError)&amp;amp;quot; equivalent for yields

Initial Comment:
The problem is already described here:
http://snakesgemscoffee.blogspot.com/2007/07/rspec-shouldyield.html

In summary:
Just like we can write:
  lambda { Client.configure(&spec_block(1)) }.should raise_error(MySpecificError)
We should also be able to write:
  lambda { Client.configure(&spec_block(1)) }.should_yield(Config)
This should mean, to the "spec_block" that expects one (1) argument of type Config.

Other suggestions for syntax are:
  lambda { Client.configure(&spec_block(1)) }.should yield_instances_of(Config)
  lambda { Client.configure(&spec_block(1)) }.should yield_objects_of(Config)
Or something else similar (these are just things that popped in my head right now.

Feedback much appreciated.

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 00:08

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/100-11949-amp-quot-should_yield-amp-quot-or-amp-quot-should-raise_error-myspecificerror-amp-quot-equivalent-for-yields#ticket-100-2

----------------------------------------------------------------------

Comment By: S. Potter (mbbx6spp)
Date: 2007-07-09 18:59

Message:
Aslak, that is very similar (with less validation) to what I
already do (as explained in the blog entry above), but
doesn't add too much value if we are following a DSL
approach in my opinion.

My thoughts on what spec_block would do is generate a block
with whatever arity is given for it.  For example, if I call
spec_block(3) that block will produce a block that has 3
arguments that cannot be ignored.  I am open to suggestions
on the naming of this helper method, but I would prefer that
the specs I write for my application don't require so much
setup to specify such a simple thing.

Those are just my thoughts and will leave this open until
there is a bit more clarity to what the RSpec developer
consensus is.  I will work on a patch based on the vision
after that point.

----------------------------------------------------------------------

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-07-09 18:18

Message:
In your example (both here and in your blog entry) - what does &spec_block(1) refer to? Is this some sort of block that would be implicitly available when yield_with (or similar) is used?

Could you use something more straightforward like this?

class Funky
  def self.bacon(&proc)
    yield '_how' if proc.arity == 1
  end
end

describe Funky do
  it "should yield when arity is 1" do
    lambda do 
      Funky.bacon do |s|
        s.should == '_how'
        throw :done
      end
    end.should throw_symbol(:done) # proves the bacon yielded
  end

  it "should not yield when arity is 2" do
    lambda do 
      Funky.bacon do
        throw :done
      end 
    end.should_not throw_symbol(:done)
  end
end


----------------------------------------------------------------------

Comment By: S. Potter (mbbx6spp)
Date: 2007-07-01 21:27

Message:
Great thanks, I'll attached to this ticket.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-07-01 21:25

Message:
Cool - I'll keep my eyes peeled for your patch. Go ahead and just attach it to this ticket - no need to make a new patch ticket - OK?

----------------------------------------------------------------------

Comment By: S. Potter (mbbx6spp)
Date: 2007-07-01 21:21

Message:
Actually that sounds great.  I wasn't convinced of my own
suggestions to be honest, just a starting point - wonderful!

I can try coming up with a patch after work days this week,
to contribute back.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-07-01 20:56

Message:
We don't want to add any more "should_xyz" methods because they have to get added directly to object. So it's got to be a matcher - the trick is coming up w/ good verbiage. How about this?

should yield_with(arg1,arg2)
should yield_with(no_args)

You would always have to supply at least one arg - but that arg could be no_args which would be the same method we use for mocks:

should_receive(:message).with(no_args)

WDYT?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=11949&group_id=797

From noreply at rubyforge.org  Mon Nov 19 00:09:42 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Nov 2007 00:09:42 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-12246 ] Support Matrix
	functional testing
Message-ID: <20071119050942.7055A18585A3@rubyforge.org>

Feature Requests item #12246, was opened at 2007-07-12 22:19
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12246&group_id=797

Category: runner module
Group: None
Status: Open
Priority: 3
Submitted By: Bin Dong (dongbin)
Assigned to: Nobody (None)
Summary: Support Matrix functional testing

Initial Comment:
http://drnicwilliams.com/2007/05/22/functional-testing-using-a-matrix-to-cover-all-edge-cases-video/

There is matrix test support in Zentest. But it can not be used by rspec.



----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 00:09

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/101-12246-support-matrix-functional-testing

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12246&group_id=797

From noreply at rubyforge.org  Mon Nov 19 00:10:13 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Nov 2007 00:10:13 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-12418 ] An option to spec
	runner to stop after first failure
Message-ID: <20071119051013.7443B18585A3@rubyforge.org>

Feature Requests item #12418, was opened at 2007-07-19 10:42
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12418&group_id=797

Category: runner / command line
Group: None
Status: Open
Priority: 3
Submitted By: Esad Hajdarevic (esad)
Assigned to: Nobody (None)
Summary: An option to spec runner to stop after first failure

Initial Comment:
I have a relatively big number of specs in the current project which take 5-10 minutes to execute. 

What I'd like to propose is an option to runner that would stop after the first spec has failed, because otherwise even after a small change I need to wait the few minutes to see what went wrong.


----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 00:10

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/102-12418-an-option-to-spec-runner-to-stop-after-first-failure

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12418&group_id=797

From noreply at rubyforge.org  Mon Nov 19 00:11:57 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Nov 2007 00:11:57 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-12418 ] An option to spec
	runner to stop after first failure
Message-ID: <20071119051157.B31E818585A3@rubyforge.org>

Feature Requests item #12418, was opened at 2007-07-19 10:42
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12418&group_id=797

Category: runner / command line
Group: None
Status: Open
Priority: 3
Submitted By: Esad Hajdarevic (esad)
Assigned to: Nobody (None)
Summary: An option to spec runner to stop after first failure

Initial Comment:
I have a relatively big number of specs in the current project which take 5-10 minutes to execute. 

What I'd like to propose is an option to runner that would stop after the first spec has failed, because otherwise even after a small change I need to wait the few minutes to see what went wrong.


----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 00:11

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/102-12418-an-option-to-spec-runner-to-stop-after-first-failure

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 00:10

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/102-12418-an-option-to-spec-runner-to-stop-after-first-failure

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12418&group_id=797

From noreply at rubyforge.org  Mon Nov 19 00:13:30 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Nov 2007 00:13:30 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-12723 ] Add a second
	reporter (HTML) to rake tasks
Message-ID: <20071119051330.CE51018585A3@rubyforge.org>

Feature Requests item #12723, was opened at 2007-07-31 16:42
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12723&group_id=797

Category: rails plugin
Group: None
Status: Open
Priority: 4
Submitted By: Aslak Helles?y (aslak_hellesoy)
Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: Add a second reporter (HTML) to rake tasks

Initial Comment:
Easy to do - just do it

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 00:13

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/103-12723-add-a-second-reporter-html-to-rake-tasks

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12723&group_id=797

From noreply at rubyforge.org  Mon Nov 19 00:14:44 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Nov 2007 00:14:44 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-12866 ] rails integration
	stories
Message-ID: <20071119051444.5314318585B1@rubyforge.org>

Feature Requests item #12866, was opened at 2007-08-07 01:17
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12866&group_id=797

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Nobody (None)
Summary: rails integration stories

Initial Comment:
Now that we're close to getting rbehave's story runner merged into rspec, we need to start looking at wrapping rails integration tests in Rspec Stories.


----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 00:14

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/104-12866-rails-integration-stories

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12866&group_id=797

From noreply at rubyforge.org  Mon Nov 19 00:15:33 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Nov 2007 00:15:33 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-12894 ] Stubs should be able
	to both return and yield a value
Message-ID: <20071119051533.8DB8B18585A3@rubyforge.org>

Feature Requests item #12894, was opened at 2007-08-07 20:42
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12894&group_id=797

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: Stubs should be able to both return and yield a value

Initial Comment:

Stubs can return values:

obj.stub!(:example_method).and_return "val"

or they could yield to values:

obj.stub!(:example_method).and_yield "val"

What if they could do both?

obj.stub!(:example_method).yield("val").and_return "val"

Better syntax is welcome.

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 00:15

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/105-12894-stubs-should-be-able-to-both-return-and-yield-a-value

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12894&group_id=797

From noreply at rubyforge.org  Mon Nov 19 00:17:07 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Nov 2007 00:17:07 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-12985 ]
	with_block_which_returns(val)
Message-ID: <20071119051707.7C31018585A3@rubyforge.org>

Feature Requests item #12985, was opened at 2007-08-10 19:25
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12985&group_id=797

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: with_block_which_returns(val)

Initial Comment:

>From the mailing list:

(me):
Maybe a better example would be in place.  Consider the following
from the Autotest plugin:

Autotest.add_discovery do
   "rspec" if File.exist?('spec')
end

How would you go about testing this?

It's easy enough to test that Autotest receives the method
add_discovery.  But how would you deal with the block?



(David:)
OK - now I'm starting to see. Concrete examples are always helpful.

I guess there's no mocking framework right now that would solve that
for you. What spec do you *wish* you could write?

----------------------

Maybe something like this:

describe Autotest::Rspec "discovery" do
  it "should take a block returns 'rspec' if the file exists" do
    File.stub!(:exists?).and_return true
    Autotest.should_receive(:add_discovery).with_block_which_returns "rspec"
  end
  
  it "should take a block which returns nil if the file does not exist" do
    File.stub!(:exists?).and_return false
    Autotest.should_receive(:add_discovery).with_block_which_returns nil
  end
end


or maybe something like this:

Autotest.should_receive(:add_discovery).with(:val1, :val2).and_block_which_returns "rspec"

I'm open to a less verbose/more terse syntax.


----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 00:17

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/106-12985-with_block_which_returns-val

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12985&group_id=797

From noreply at rubyforge.org  Mon Nov 19 00:17:42 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Nov 2007 00:17:42 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-13126 ] move rspec/spec.opts
	to rspec/spec/spec.opts
Message-ID: <20071119051742.4CF91185859A@rubyforge.org>

Feature Requests item #13126, was opened at 2007-08-16 04:35
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13126&group_id=797

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: move rspec/spec.opts to rspec/spec/spec.opts

Initial Comment:

Not really a feature request, per se, but I think it would be nice to have rspec/spec.opts moved to rspec/spec/spec.opts for autotest compatibility when developing rspec.



----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 00:17

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/107-13126-move-rspec-spec-opts-to-rspec-spec-spec-opts

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13126&group_id=797

From noreply at rubyforge.org  Mon Nov 19 00:18:24 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Nov 2007 00:18:24 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-13140 ] Make it easier to
	use the runner objects
Message-ID: <20071119051824.D463E185859A@rubyforge.org>

Feature Requests item #13140, was opened at 2007-08-16 15:58
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13140&group_id=797

Category: runner / command line
Group: None
Status: Open
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: Make it easier to use the runner objects

Initial Comment:
There are issues with invoking the runner directly because the first time Kernel#behaviour_runner is called, an at_exit block is created.

It would be useful get rid of this behaviour because this makes is difficult to work with the runner object model.

Currently to get around this, I need to assign the $behaviour_runner global variable before the first call to Kernel#behaviour_runner.

Also as of 1.0.8, I need to call Options#configure or a reporter will not be assigned.
options = ::Spec::Runner::OptionParser.new.parse(ARGV.dup, STDERR, STDOUT, false)
options.configure 
$behaviour_runner = options.create_behaviour_runner

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 00:18

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/108-13140-make-it-easier-to-use-the-runner-objects

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13140&group_id=797

From noreply at rubyforge.org  Mon Nov 19 00:19:21 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Nov 2007 00:19:21 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-13326 ] add a parameter will
	be more convenient
Message-ID: <20071119051921.2879C18585B1@rubyforge.org>

Feature Requests item #13326, was opened at 2007-08-24 05:39
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13326&group_id=797

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: xiaoming lin (linxiaoming)
Assigned to: Nobody (None)
Summary: add a parameter will be more convenient  

Initial Comment:
Spec::Runner::Formatter::HtmlFormatter

class WebTestHtmlFormatter < Spec::Runner::Formatter::HtmlFormatter
  def extra_failure_content(failure)
    #print "aaa"
    #print failure.to_s
    #@output.puts "HTML source1" 
    @behaviour_red = true
    move_progress
    @output.puts "    <dd class=\spec failed\>"
    @output.puts "      <span class=\failed_spec_name\>abcdefg</span>"
 end
end

...

But I want to use the example object in WebTestHtmlFormatter?
but I can't accept the example object?

Is this a good idea?
#####def extra_failure_content(failure,example)####

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 00:19

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/109-13326-add-a-parameter-will-be-more-convenient#ticket-109-2

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-09-23 17:00

Message:
Moving this over to feature requests. It's not really a bug.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13326&group_id=797

From noreply at rubyforge.org  Mon Nov 19 00:21:15 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Nov 2007 00:21:15 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-13487 ] Parameterize Shared
	Behaviours
Message-ID: <20071119052115.1E206185859A@rubyforge.org>

Feature Requests item #13487, was opened at 2007-08-29 09:42
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13487&group_id=797

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Nobody (None)
Summary: Parameterize Shared Behaviours

Initial Comment:
There has been discussion of parameterized shared behaviours, but t

The current implementation of shared behaviours copies examples into the execution scope of the including behaviour. This gives the examples access to state defined in before(:each) in the including example. This works well, but does some a bit like black magic:

describe "a RESTful controller", :shared => true do
  it "should find all instances of the resource" do
    @model_class.should_receive(:find).with(:all)
    get 'index'
  end
end

describe FooController do
  before(:each) do
    @model_class = Foo
  end
  it_should_behave_like "a RESTful controller"
end

The steps in the new Story Runner (Given, When, Then) all take arguments, supporting reusable blocks. We should do the same thing with shared behaviours. 

I think that parameterizing these would be a cleaner solution, but I think it would require a separate construct (internally) than the one we have - if parameterized it should not share state with the including behaviour. But I can imagine something like this:

#DOES NOT EXIST YET
describe "a RESTful controller" do |model_class|
  it "should find all instances of the resource" do
    model_class.should_receive(:find).with(:all)
    get 'index'
  end
end

describe FooController do
  #DOES NOT EXIST YET
  it_should_behave_like "a RESTful controller", Foo
end

We might not even need the :shared => true flag if the describe block has block args - arity > 0 could be the indicator to share.

Now this approach has it's drawbacks as well. If you end up w/ a long list of block args, you'd best get them in the right order. Sharing instance variables is its own brand of voodoo, but at least you can name them well. I guess we could add a hash:

  it_should_behave_like "a RESTful controller", :model_class => Foo

But that starts to get ugly pretty quickly as well.

Thoughts?

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 00:21

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/110-13487-parameterize-shared-behaviours#ticket-110-2

----------------------------------------------------------------------

Comment By: Assaf Arkin (assaf)
Date: 2007-09-12 20:06

Message:
I would prefer to get rid of :shared=>true by adding a new method, say shared instead of describe.  It's easier to scan through the code and identity the shared behaviors.  Arity would make sense when I'm writing a shared behavior, but much harder to spot them when I'm reading the code.

And another +1 to parameterizing shared behaviors.  Right now I handle that by defining a method for use by the  shared behavior assumes exist, so:

  describe "using shared" do
    it_should_behave_like "a RESTful controller"
    define_method(:model_class) { Foo }
  end

This can be done with hashes (create methods to hold those values), or named arguments, but unfortunately not both.

----------------------------------------------------------------------

Comment By: Tom Stuart (tstuart)
Date: 2007-08-30 03:33

Message:
David: in the vaguely-analogous case of Rails partials, controller state is shared (i.e. access to the instance variables still works) even when the partial is parameterised (i.e. render :partial => ..., :locals => { ... }), so the combination of both in shared behaviours may feel familiar to Rails users at least.

----------------------------------------------------------------------

Comment By: Dan North (tastapod)
Date: 2007-08-29 19:27

Message:
I'm  missing something here. Can't all this shared behaviour just be achieved using mixins?

module BehavesLikeARestfulController
  # expects @model_class to be defined

  it "should find all instances of the resource" do
    @model_class.should_receive(:find).with(:all)
    get 'index'
  end
end

describe FooController do
  @model_class = Foo
  include BehavesLikeARestfulController
end

The example runner will re-initialise @model_class for each example (it-block) in the mixin because each one runs in a separate object instance.

Also, you can put before(:each) code in the module to make it self-contained, and the runner should Do The Right Thing (i.e. add it to any additional before(:each) in the specific describe block).

How does this help me? I wasn't around for the original conversations that led to :shared behaviours in the first place, so apologies if I'm going over old ground.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-29 16:18

Message:
I was thinking it should either be shared state or parameterized, but not both. That strikes me as the least confusing option. But I'm convincable.

----------------------------------------------------------------------

Comment By: Ian Dees (undees)
Date: 2007-08-29 15:22

Message:
+1 on letting the describe block's arity indicate shared-itude.

>From there, the test author can choose whether to put a few block parameters in a row or use a single hash parameter.

If this gets implemented, are you going to revoke shared behaviors' access to the state of the describe block where they're used?  I could see this causing confusion.  After all, shared Given/When/Then blocks definitely have access to their Scenario's state.

----------------------------------------------------------------------

Comment By: Tom Stuart (tstuart)
Date: 2007-08-29 10:44

Message:
This functionality would presumably be used in the presence of inheritance (or mixins etc) in the code being specified, so it'd be nice to support something that behaves like spec inheritance, e.g. the ability to extend or override individual shared behaviors, but it's hard to see how that could work. It's certainly easier to demand that shared behaviors be kept fine-grained enough to be mixed-and-matched as required.

----------------------------------------------------------------------

Comment By: Tom Stuart (tstuart)
Date: 2007-08-29 10:35

Message:
Using a hash looks ugly but arguably is more natural and provides maximum flexibility, particularly in a situation where one has a healthy set of default options and wants to tweak individual values as necessary:

 describe FooController do
   it_should_behave_like "a RESTful controller", options.merge { :model_class => Foo }
 end

Of course, if you do it with block args then this is already available to the user as a special case!

The idea of getting rid of :shared => true in the presence of describe block args is really cool.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13487&group_id=797

From noreply at rubyforge.org  Mon Nov 19 00:22:11 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Nov 2007 00:22:11 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-13492 ] Support
	parameterized Examples ala TestNG's DataProvider
Message-ID: <20071119052211.67F00185859A@rubyforge.org>

Feature Requests item #13492, was opened at 2007-08-29 12:50
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13492&group_id=797

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Bob Cotton (bcotton)
Assigned to: Nobody (None)
Summary: Support parameterized Examples ala TestNG's DataProvider

Initial Comment:
In response to http://rubyforge.org//tracker/index.php?func=detail&aid=13487&group_id=797&atid=3152

While you're thinking of parameterizing things, I was thinking about how to introduce TestNG's concept of data providers. See http://debasishg.blogspot.com/2007/05/parameterizing-test-methods-revisited.html for a discussion.

If the block passed to an Example could be parameterized it might look like this:

it "should be parameterized", :data_provider => my_data_provider_method do |arg1, arg2| 
end

Then the example would be called once each time #my_data_provider_method didn't return nil.


Thoughts?

- Bob

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 00:22

Message:
 Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/111-13492-support-parameterized-examples-ala-testng-s-dataprovider

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13492&group_id=797

From noreply at rubyforge.org  Mon Nov 19 00:23:16 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Nov 2007 00:23:16 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-13540 ] [Story Runner] dry
	run should show all of the steps, even after one that fails
Message-ID: <20071119052316.3E24A185859A@rubyforge.org>

Feature Requests item #13540, was opened at 2007-08-30 20:56
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13540&group_id=797

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Dan North (tastapod)
Summary: [Story Runner] dry run should show all of the steps, even after one that fails

Initial Comment:
I've got a Scenario which is failing at a step in the middle. When I run:

  ruby stories/user_changes_password.rb

the output does not include all of the steps, but does show the error that occurs in the last step that was executed.

When I run:

  ruby stories/user_changes_password.rb --dry-run

the output, again, does not include all of the steps, even though it doesn't give you the impression that any steps are actually getting executed.

I think you should see all of the steps when doing a dry run. In fact, I really think you should see all of the steps even when one fails. This is high level stuff - 'fail fast' doesn't have the same meaning here as it does when doing TDD at the object level.

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 00:23

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/112-13540-story-runner-dry-run-should-show-all-of-the-steps-even-after-one-that-fails#ticket-112-2

----------------------------------------------------------------------

Comment By: Ian Dees (undees)
Date: 2007-08-31 14:52

Message:
FWIW, we ran into this all the time with our old, homegrown GUI tests (and will no doubt face it again when we start writing longer Stories).  Do we stop and give up, or keep going?

For us, the answer was, "it depends."  If a test failed -- a control caption didn't match or something -- we'd soldier bravely on.

But if a test threw an exception (other than an "expectation not met," of course) -- maybe a particular window completely failed to appear -- then we'd bail out of the entire script, and hope the next script had better luck.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-31 05:43

Message:
I think that, for a tool that operates at a high level, running subsequent makes perfect sense.

Using the map analogy, you wouldn't forget to turn left executing a Story - you would FAIL to turn left because there was some road block - but what if the subsequent two rights and a left all failed too? Now you're back on the same road! Then the subsequent steps make sense.

Also - not all steps in a Story are necessary at the code level, even though they may be useful at the story-telling level.

The story-level tool that I 'grew up on' was FitNesse, based on FIT. In FIT, the entire story gets played out on each page, regardless of where failures are. In my experience as a developer using those failures to guide my next steps at the code level, having the later steps pass or fail provides valuable information as to where I am in relation to DONE. And that's a very important point of this process, isn't it?

----------------------------------------------------------------------

Comment By: Dan North (tastapod)
Date: 2007-08-31 05:33

Message:
It's definitely a bug if it isn't printing all the steps in a dry run. Can you post an example?

A scenario should always "fail fast", but at the scenario level (i.e. any subsequent scenarios will always be run).

Running subsequent steps after a failure doesn't make any sense. Imagine following a list of map directions. Halfway down the list you forget to "turn left", but carrying on following the list anyway: "turn right at the warehouse" - what warehouse? "then straight ahead at the river" - eh?). By definition you are in an inconsistent or unrecoverable state after a failed step.

Although... that does suddenly introduce the possibility for a RecoverableStep, or maybe an OptionalStep - hmm. But not on this bug report :)

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13540&group_id=797

From noreply at rubyforge.org  Mon Nov 19 00:23:47 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Nov 2007 00:23:47 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-13547 ] [Story Runner] html
	formatted output
Message-ID: <20071119052347.2C188185859A@rubyforge.org>

Feature Requests item #13547, was opened at 2007-08-31 05:01
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13547&group_id=797

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Nobody (None)
Summary: [Story Runner] html formatted output

Initial Comment:
Add html format for Story Runner

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 00:23

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/113-13547-story-runner-html-formatted-output

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13547&group_id=797

From noreply at rubyforge.org  Mon Nov 19 00:24:25 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Nov 2007 00:24:25 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-13574 ] cleaner syntax for
	consecutive return values
Message-ID: <20071119052425.A474B18585A3@rubyforge.org>

Feature Requests item #13574, was opened at 2007-09-01 10:03
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13574&group_id=797

Category: mock module
Group: None
Status: Open
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Nobody (None)
Summary: cleaner syntax for consecutive return values

Initial Comment:
We just added this to trunk for multiple yields:

@mock.should_receive(:message).once.
  and_yield('wha', 'zup').
  and_yield('not', 'down').
  and_yield(14, 65)

We should do something similar for consecutive returns:

@mock.should_receive(:message).
  and_return('wha', 'zup').
  and_return('not', 'down').
  and_return(14, 65)



----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 00:24

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/114-13574-cleaner-syntax-for-consecutive-return-values

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13574&group_id=797

From noreply at rubyforge.org  Mon Nov 19 00:26:11 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Nov 2007 00:26:11 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-13616 ] [CODE included]
	Testing RJS helper methods
Message-ID: <20071119052611.E492F18585A3@rubyforge.org>

Feature Requests item #13616, was opened at 2007-09-03 07:23
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13616&group_id=797

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Simon Nicholls (simon_nicholls)
Assigned to: Nobody (None)
Summary: [CODE included] Testing RJS helper methods

Initial Comment:
Hi,

I like to test my RJS helper methods using RSpec. These are the helper methods that have a page object implicitly provided for their use.

As an example, for:

update_page {|page| page.notify("kitten")} in the controller

With the helper being:

def notify(message)
  page[:notice].replace_html message
end

I can do:

describe AjaxHelper, "notify" do
  it "should update notice area" do
    rjs_for.notify("kitten").should have_rjs(:chained_replace_html, "notice")
  end
end

To do this, I include a Helper module, but it could be in core using code similar to the following (all in dsl/behaviour/helper.rb).

In ExampleMethods module, alongside eval_erb:

def rjs_for
  HelperRJSPageProxy.new(self)
end

Then where other classes are defined (e.g. HelperEvalContextController):

class HelperRJSPageProxy
  def initialize(context)
    @context = context
  end

  def method_missing(method, *arguments)
    block = Proc.new { |page|  @lines = []; page.send(method, *arguments) }
    @context.response.body = ActionView::Helpers::PrototypeHelper::JavaScriptGenerator.new(@context, &block).to_s
    @context.response
  end
end

I checked out the RSpec trunk, thinking to make a patch, but failed to get far with understanding RSpec's own spec layout and speccing the spec.

Hope you find the code useful! It's been handy to be able to test RJS helpers, and it would be great to have in core.

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 00:26

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/115-13616-code-included-testing-rjs-helper-methods

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13616&group_id=797

From noreply at rubyforge.org  Mon Nov 19 00:26:51 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Nov 2007 00:26:51 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-13645 ] Support for
	alternative expectations
Message-ID: <20071119052651.A19A618585B2@rubyforge.org>

Feature Requests item #13645, was opened at 2007-09-04 06:33
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13645&group_id=797

Category: mock module
Group: None
Status: Open
Priority: 3
Submitted By: Rodrigo Alvarez (papipo)
Assigned to: Nobody (None)
Summary: Support for alternative expectations

Initial Comment:
I would like to be able to do something like:

@model.should_receive(:save).and_return(true).or_receive(:save!).and_raise(ActiveRecord::RecordNotSaved)

At the moment I must stub both methods, and that does the work, but that way I'm not specifying what is supposed to happen. 

This allows more verbosity.

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 00:26

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/116-13645-support-for-alternative-expectations

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13645&group_id=797

From undees at gmail.com  Mon Nov 19 00:27:21 2007
From: undees at gmail.com (Ian Dees)
Date: Sun, 18 Nov 2007 21:27:21 -0800
Subject: [rspec-devel] [ANN] Lighthouse and Engine Yard sponsorships
Message-ID: <ad4f9af90711182127k39164b25re91e0fb8ae65e830@mail.gmail.com>

> We're also going to be getting a sponsored slice at Engine Yard[3] to
> host source control, which will be either mercurial or git (TBD but
> we're leaning towards mercurial).

-1 Git
+1 Mercurial

If the installation process (Cygwin) and speed (glacial) are anything
to go by, Git is pretty Windows-hostile.

--Ian

From noreply at rubyforge.org  Mon Nov 19 00:27:45 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Nov 2007 00:27:45 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-13661 ] View Specs - Allow
	controller to be defined (default to ApplicationController)
Message-ID: <20071119052745.911B518585BD@rubyforge.org>

Feature Requests item #13661, was opened at 2007-09-04 19:29
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13661&group_id=797

Category: rails plugin
Group: None
Status: Open
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: View Specs - Allow controller to be defined (default to ApplicationController)

Initial Comment:
This will give the view access to helper_methods defined in the controller.

e.g.

describe "foo/show.erb" do
  controller_name "foo"

  it "should have method defined from foo controller" do
    template.foobar.should == "I'm defined in FooController"
  end
end


----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 00:27

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/117-13661-view-specs-allow-controller-to-be-defined-default-to-applicationcontroller

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13661&group_id=797

From noreply at rubyforge.org  Mon Nov 19 00:29:16 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Nov 2007 00:29:16 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-13856 ] Show Pending
	Messages in RSpec Report
Message-ID: <20071119052916.5F77318585B7@rubyforge.org>

Feature Requests item #13856, was opened at 2007-09-11 17:27
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13856&group_id=797

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Geoffrey Wiseman (diathesis)
Assigned to: Nobody (None)
Summary: Show Pending Messages in RSpec Report

Initial Comment:
When the spec contains an explicit pending message, e.g.:

  describe "Secure passwords with MD5" do
    pending "Waiting on selection of an MD5 library."
  end

It'd be nice if this were visible in the RSpec HTML report.  Currently, the HTML report contains 'Secure passwords with MD5' as pending, but does not add the explanation as to why.


----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 00:29

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/118-13856-show-pending-messages-in-rspec-report#ticket-118-2

----------------------------------------------------------------------

Comment By: Bryan Helmkamp (brynary)
Date: 2007-10-03 02:10

Message:
Patch submitted: http://rubyforge.org/tracker/index.php?func=detail&aid=14399&group_id=797&atid=3151

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13856&group_id=797

From noreply at rubyforge.org  Mon Nov 19 00:30:07 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Nov 2007 00:30:07 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-13857 ] Show/Hide Spec
	Source in RSpec HTML Report
Message-ID: <20071119053007.4908818585B7@rubyforge.org>

Feature Requests item #13857, was opened at 2007-09-11 17:29
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13857&group_id=797

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Geoffrey Wiseman (diathesis)
Assigned to: Nobody (None)
Summary: Show/Hide Spec Source in RSpec HTML Report

Initial Comment:
It would be nice to be able to use DHTML expansion to see the source of the spec, sometimes.  When we're doing walkthroughs with the customer representative, it's useful for him to be able to see the source as well as the descriptions.

Sometimes, this might be a sign that we haven't achieved as fine a granularity as  we should in the descriptions, but when he has questions about the details, it would still be nice to be able to bring it up.  I wouldn't want to clutter the report with this, but if it were handled through judicious use of DHTML, it might be possible to accomplish this with minimal ugliness.

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 00:30

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/119-13857-show-hide-spec-source-in-rspec-html-report

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13857&group_id=797

From nathan.sutton at gmail.com  Mon Nov 19 00:30:00 2007
From: nathan.sutton at gmail.com (Nathan Sutton)
Date: Sun, 18 Nov 2007 23:30:00 -0600
Subject: [rspec-devel] [ANN] Lighthouse and Engine Yard sponsorships
In-Reply-To: <ad4f9af90711182127k39164b25re91e0fb8ae65e830@mail.gmail.com>
References: <ad4f9af90711182127k39164b25re91e0fb8ae65e830@mail.gmail.com>
Message-ID: <3D07603D-3D42-414F-8734-8A59431CE87C@gmail.com>

How many people do ruby dev on windows?  I sympathize with your  
situation, but if git is superior and few people use windows, yeah...

Nathan Sutton
fowlduck at gmail.com
rspec edge revision 2910
rspec_on_rails edge revision 2909
rails edge revision 8167





On Nov 18, 2007, at 11:27 PM, Ian Dees wrote:

>> We're also going to be getting a sponsored slice at Engine Yard[3] to
>> host source control, which will be either mercurial or git (TBD but
>> we're leaning towards mercurial).
>
> -1 Git
> +1 Mercurial
>
> If the installation process (Cygwin) and speed (glacial) are anything
> to go by, Git is pretty Windows-hostile.
>
> --Ian
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From noreply at rubyforge.org  Mon Nov 19 00:31:18 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Nov 2007 00:31:18 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-13885 ] be_status methods
Message-ID: <20071119053118.314F518585B7@rubyforge.org>

Feature Requests item #13885, was opened at 2007-09-12 20:11
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13885&group_id=797

Category: rails plugin
Group: None
Status: Open
Priority: 3
Submitted By: Assaf Arkin (assaf)
Assigned to: Nobody (None)
Summary: be_status methods

Initial Comment:
response.should be_successful or response.should be_missing are nice but not enough.  In too many cases I'm looking for response codes that are neither 200 nor 404.

So how about adding all the status symbols as tests methods?

Controller:
  head :unauthorized
Spec:
  response.should be_unauthorized

Controller:
  head :gone
Spec:
  response.should be_gone

And so forth.  This code will do it for anything using controller (TestResponse) and integration (CgiResponse) tests:

module ActionController
  # TestResponse for functional, CgiResponse for integration.
  class AbstractResponse
    StatusCodes::SYMBOL_TO_STATUS_CODE.each do |symbol, code|
      define_method("#{symbol}?") { self.response_code == code } unless instance_methods.include?("#{symbol}?")
    end
  end
end

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 00:31

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/120-13885-be_status-methods#ticket-120-2

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-09-23 18:17

Message:
I'll add this if you'll submit it as a patch with specs.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13885&group_id=797

From noreply at rubyforge.org  Mon Nov 19 00:32:22 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Nov 2007 00:32:22 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-14304 ] Specify the
	controller request in the description options
Message-ID: <20071119053222.D0C3A18585B7@rubyforge.org>

Feature Requests item #14304, was opened at 2007-09-28 12:39
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=14304&group_id=797

Category: rails plugin
Group: None
Status: Open
Priority: 3
Submitted By: Jonathan Leighton (jonleighton)
Assigned to: Nobody (None)
Summary: Specify the controller request in the description options

Initial Comment:
I was experimenting with metaprogramming some of my examples, in order to keep my specs DRY, and I needed some way to programmatically specify what the request being tested was. I came up with this:

describe ArticlesController, :request => { :get => :show, :id => 53 } do
  it "should find the article" do
    Article.expects(:find).with(53)
    send_request
  end
end

Here is my code: http://pastie.caboo.se/101764

I would be willing to make this into a patch if it sounds like a good idea?

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 00:32

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/121-14304-specify-the-controller-request-in-the-description-options

----------------------------------------------------------------------

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-10-06 14:08

Message:
Personally, I really like this option.  I've found myself doing the same thing over and over again:

describe SomeController do
  def do_action
    get :something, :id => 1
  end

  it "should blah blah" do
    do_action
    assertion
  end

  it "should do blah blah" do
    assertion
    do_action
  end

  # ...

end


The question is not whether RSpec is too bloated (nor that the example is not DRY)- the question is if it makes the tests more *readable* or understandable.  Maybe with the right syntax it would.  

----------------------------------------------------------------------

Comment By: Jonathan Leighton (jonleighton)
Date: 2007-10-06 11:36

Message:
Mike: I agree with you in general but I created it in order
to solve the problem of knowing what request to use if I was
defining my own example generator such as
"it_should_redirect_to :index".

I guess another approach might be to have the last argument
specify the request, eg:

it_should_redirect_to :index, :get => :create

I'm going to stick a post on my blog about it, though I
doubt many people will read that ;)

----------------------------------------------------------------------

Comment By: Mike Mangino (mmangino)
Date: 2007-09-30 21:16

Message:
I don't care for this at all. If you want this behavior, you could easily define the send_request method yourself. It just seems like a really obscure syntax. I'd rather the action performed by send_request be made more explicit.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-09-30 11:05

Message:
It sounds like a good idea, but I'd like to get more feedback first.

How about blogging it or releasing it as a plugin so people can get some experience with it. If the feedback is generally positive I'd be open to adding it.

The only reason I'm not jumping on it is that I've been feeling as though RSpec has become too bloated as it is, and I'm hesitant to add any new features without careful consideration.

It does sound like a good idea, and I'll be exploring it myself on my own projects.

Cheers,
David

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=14304&group_id=797

From noreply at rubyforge.org  Mon Nov 19 00:33:29 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Nov 2007 00:33:29 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-14391 ] .should respond_to()
	vs respond_to?()
Message-ID: <20071119053329.30DB618585B7@rubyforge.org>

Feature Requests item #14391, was opened at 2007-10-02 18:00
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=14391&group_id=797

Category: expectation module
Group: None
Status: Open
Priority: 3
Submitted By: Garrett Heaver (garrettheaver)
Assigned to: David Chelimsky (dchelimsky)
Summary: .should respond_to() vs respond_to?()

Initial Comment:
In Rails, when methods are declared on an association such as a has_many, these methods are not visible to the respond_to() rSpec method.

for example:

class Item < ActiveRecord::Base
has_many :translations do
    def active
        find(:first, :conditions => {:language_id, Language.active.id})
    end
end
end

it "should add an active method to the translations association" do
  @item.translations.should respond_to(:active)
end

^^ will never pass, however

it "should add an active method to the translations association" do
  @item.translations.respond_to?(:active).should be_true
end

^^ will pass

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 00:33

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/122-14391-should-respond_to-vs-respond_to#ticket-122-2

----------------------------------------------------------------------

Comment By: Garrett Heaver (garrettheaver)
Date: 2007-10-02 18:09

Message:
If you think it belongs better as that David, absolutly.

I'm going to try and dig into it a bit myself but someone who knows the matcher 
better might well beat me to it.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-02 18:05

Message:
This strikes me as a bug rather than a feature request - agree?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=14391&group_id=797

From noreply at rubyforge.org  Mon Nov 19 00:34:49 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Nov 2007 00:34:49 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-14867 ] Allow setting of
	default options in the spec_helper file
Message-ID: <20071119053449.56C7718585B7@rubyforge.org>

Feature Requests item #14867, was opened at 2007-10-18 19:30
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=14867&group_id=797

Category: runner / command line
Group: None
Status: Open
Priority: 3
Submitted By: Luke Kanies (lkanies)
Assigned to: Nobody (None)
Summary: Allow setting of default options in the spec_helper file

Initial Comment:
Hullo,

I'd like to be able to set default options in Ruby, rather than having to use the -O flag to load an options file.

It'd be especially nice if I could do this via the block attached to Spec::Runner.configure.

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 00:34

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/123-14867-allow-setting-of-default-options-in-the-spec_helper-file

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=14867&group_id=797

From noreply at rubyforge.org  Mon Nov 19 00:35:17 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Nov 2007 00:35:17 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-14868 ] Migrate test DB
	independent of dev DB
Message-ID: <20071119053517.817FC18585B7@rubyforge.org>

Feature Requests item #14868, was opened at 2007-10-19 00:38
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=14868&group_id=797

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Steve V (vertebrate)
Assigned to: Nobody (None)
Summary: Migrate test DB independent of dev DB

Initial Comment:
Current behavior has the test database only being migrated as far as the dev database. If doing true BDD you will be testing before going to the dev env. As such, when running specs the database should be performed to the latest migration, and give no concern to the dev DB.

This request is a result of the users list thread "spec:models depends on development db:migration"


----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 00:35

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/124-14868-migrate-test-db-independent-of-dev-db

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=14868&group_id=797

From noreply at rubyforge.org  Mon Nov 19 00:35:56 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Nov 2007 00:35:56 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-14901 ] add unit_record (or
	similar) support
Message-ID: <20071119053556.ABDA818585B7@rubyforge.org>

Feature Requests item #14901, was opened at 2007-10-20 16:03
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=14901&group_id=797

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Nobody (None)
Summary: add unit_record (or similar) support

Initial Comment:
unit_record allows you to enforce a rule that your tests never touch the database.

This request is that RSpec provide support for something similar, but that it be configurable at the spec level - so you can have arbitrary groups of specs that are not allowed to touch the DB and others that are.

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 00:35

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/125-14901-add-unit_record-or-similar-support#ticket-125-2

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-20 16:06

Message:
FYI:

http://www.dcmanges.com/blog/rails-unit-record-test-without-the-database

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=14901&group_id=797

From noreply at rubyforge.org  Mon Nov 19 00:36:36 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Nov 2007 00:36:36 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-14969 ] 'render' should
	support :text property like rails
Message-ID: <20071119053636.A850D18585B7@rubyforge.org>

Feature Requests item #14969, was opened at 2007-10-22 23:15
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=14969&group_id=797

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Steve V (vertebrate)
Assigned to: Nobody (None)
Summary: 'render' should support :text property like rails

Initial Comment:
The 'render' method for views should support a :text attribute similar to the 'render' method for Rails. One example of its usefulness would be in verifying that a layout calls yield.

render :text => '<div>yielded</div>', :layout => 'application'
response.should have_tag('div', 'yielded')

This is being posted as requested in the users list thread "Testing layouts with RSpec on Rails"

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 00:36

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/126-14969-render-should-support-text-property-like-rails

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=14969&group_id=797

From noreply at rubyforge.org  Mon Nov 19 00:38:08 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Nov 2007 00:38:08 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-14980 ] Nested Behaviour --
	reopened
Message-ID: <20071119053808.1247418585B7@rubyforge.org>

Feature Requests item #14980, was opened at 2007-10-23 04:15
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=14980&group_id=797

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: Nested Behaviour -- reopened

Initial Comment:
I'd like to reopen discussion for Nested Behaviour. On my current project, we are in a situation where nested describe blocks would be an elegant way to organize our examples.

It should be easy to implement given the current state of the source.
All that needs to be done is have Example.describe create a subclass of the current class.

Currently, here is our setup:

module AssociationMethods
  describe Person, "#games" do
  end
end

module CustomMethods
  describe Person, "#current_game" do
  end
end

Having nested describe blocks would allow:
describe Person, "association methods" do
  describe Person, "#games" do
  end
end

describe Person, "custom methods" do
  describe Person, "#current_game" do
  end
end

Also nested behaviour would allow sharing of before and after blocks.

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 00:38

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/127-14980-nested-behaviour-reopened#ticket-127-2

----------------------------------------------------------------------

Comment By: Brian Takita (btakita)
Date: 2007-10-24 02:35

Message:
First, I'd like to frame this with the status of the current
implementation:
There is an Example class. In rspec on rails, there is also
a RailsExample, ModelExample, ControllerExample,
ViewExample, and HelperExample.

before and after callbacks are registered on one of the
Example classes (aka Behaviours). When we get the callbacks
for a particular class, we also get the callbacks of the
superclasses.

For example, in a ModelExample before(:each), we get the
callbacks for:
Example.before(:each)
RailsExample.before(:each)
ModelExample.before(:each)

For after(:all), the order is:
ModelExample.before(:all)
RailsExample.before(:all)
Example.before(:all)

So there is a systematic way to get the before and after
callbacks based on inheritance.

I think the Example.behaviour method (nested behaviours)
would create a subclass of whatever class it is called from.
This would then use the existing before and after callback
structure.

So in reality, nesting describe blocks would be equivalent
to subclassing, which is something that rspec handles well
right now. I don't think it would be any more difficult to
debug than ordinary subclassing once the user knows that its
really inheritance being used.

I admit that this is probably an advanced feature. I propose
that we have a switch to turn it "on". The default will be
to not have this behaviour. If somebody wants to use it,
then they can call a method in Configuration.
This way, a fork will not be necessary.
I think that both the nested describes and the switch would
be simple to implement, since rspec is already architected
in the right way.


----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-23 09:59

Message:
... in fact, I'm so open that here is my proposal:

First let's close the loop on 1.1.0 issues and get that puppy out.

Once that's released, you should feel free to create a branch for this. It would be up to you to maintain it, keep it up to date w/ changes from trunk, etc. It would also be up to you to tend to questions on the mailing list related to this feature (and you can expect some from me as I'll be experimenting).

After some time, if people are using it and it is proving more beneficial than harmful, we can consider moving it into the trunk.

So a temporary fork of sorts. WDYT?

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-23 09:33

Message:
Well, as you might imagine, I am very resistant to this. First, a few questions:

What would be the order of precedence of befores and afters?
What about a before(:all) or after(:all)?
How would they relate to the befores/afters set up globally?
What would the output look like?
Would the output be nested too? How deeply? Is there a limit?
Can we have examples inside the outer spec?
What is the scope of helper methods?
What happens with the --reverse flag.

I'm sure there are more of these questions that I'm not thinking of yet. I really think that this would open up a can of procedural worms that I'd be inclined to leave closed.

Additionally, even if all of my questions are answered easily, I can guarantee that it will lead to long debugging sessions focused on specs, which is exactly the opposite of where rspec should take you. I'd really hate to see the rspec lists get flooded with questions from people who are creating deeply nested hierarchies of specs and having trouble understanding why they aren't working. That's just not what this is all about.

My vote is nay.

But I'm open :)


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=14980&group_id=797

From noreply at rubyforge.org  Mon Nov 19 00:38:41 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Nov 2007 00:38:41 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-14989 ] validate options in
	hashes passed to various methods like describe
Message-ID: <20071119053841.6260218585CB@rubyforge.org>

Feature Requests item #14989, was opened at 2007-10-23 13:19
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=14989&group_id=797

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Nobody (None)
Summary: validate options in hashes passed to various methods like describe

Initial Comment:
If I accidentally type :behavior_type instead of :behaviour_type, I get unexpected results and waste time debugging them.

It would be nice if the options hash passed to #describe was validated.

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 00:38

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/128-14989-validate-options-in-hashes-passed-to-various-methods-like-describe

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=14989&group_id=797

From noreply at rubyforge.org  Mon Nov 19 00:39:27 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Nov 2007 00:39:27 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-15088 ] Nested behaviour
	descriptions
Message-ID: <20071119053927.52B5F18585B7@rubyforge.org>

Feature Requests item #15088, was opened at 2007-10-26 15:16
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=15088&group_id=797

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: Nested behaviour descriptions

Initial Comment:
This is a prerequisite to the Nested behaviour story.

class FooSpec < Spec::DSL::Example
  describe Foo
end

class DoingThisSpec < FooSpec
  describe "doing this"
  it "should blah" {}
end

class DoingThatSpec < FooSpec
  describe "doing that"
end

Would generate something like:
Foo:
- doing this:
-- should blah
- doing that:
-- should halb


----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 00:39

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/129-15088-nested-behaviour-descriptions

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=15088&group_id=797

From noreply at rubyforge.org  Mon Nov 19 00:39:52 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Nov 2007 00:39:52 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-15247 ] Heckle task
Message-ID: <20071119053952.DC3A418585C2@rubyforge.org>

Feature Requests item #15247, was opened at 2007-10-31 17:46
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=15247&group_id=797

Category: Rake
Group: None
Status: Open
Priority: 3
Submitted By: Ashley Moran (ashleymoran)
Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: Heckle task

Initial Comment:
Any chance of a heckle option in Spec::Rake::SpecTask, similar to the way you can use rcov?

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 00:39

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/130-15247-heckle-task

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=15247&group_id=797

From noreply at rubyforge.org  Mon Nov 19 00:40:19 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Nov 2007 00:40:19 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-15261 ] Green descriptions
	are also clickable
Message-ID: <20071119054019.7ED2418585C2@rubyforge.org>

Feature Requests item #15261, was opened at 2007-11-01 11: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.  

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 00:40

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/131-15261-green-descriptions-are-also-clickable

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=15261&group_id=797

From chad at spicycode.com  Mon Nov 19 00:41:53 2007
From: chad at spicycode.com (Chad Humphries)
Date: Mon, 19 Nov 2007 00:41:53 -0500
Subject: [rspec-devel] [rspec-users] help anyone?
In-Reply-To: <57c63afe0711181426m10730239g3b8c7f4c52c390e3@mail.gmail.com>
References: <57c63afe0711181316l7875bcdcsda1927b9e61f6b0e@mail.gmail.com>
	<C33E9BF7-9B2C-4934-B7D6-C6708E1FFA61@parkerhill.com>
	<57c63afe0711181426m10730239g3b8c7f4c52c390e3@mail.gmail.com>
Message-ID: <DA40C681-6D8B-4FE0-9D67-68CE011A6CEC@spicycode.com>

David,

The move should be complete now.

-Chad

On Nov 18, 2007, at 5:26 PM, David Chelimsky wrote:

> On Nov 18, 2007 4:16 PM, Jonathan Linowes <jonathan at parkerhill.com>  
> wrote:
>> David,
>>
>> If no one else offers a more efficient solution, I'm willing to
>> manually copy the open tickets. (I count 37 of them)
>> I have read access to Rubyforge
>> and see this as an opportunity to get familiar with lighthouse
>
> Thanks Jonathan, but Chad Humpries has already offered to do this (on
> the rspec-devel list).
>
> Also - there are 37 but there are also 9 patches and 77 feature
> requests. We need them all to get moved over.
>
> If you want to coordinate w/ Chad and Scott (who also volunteered),
> perhaps you guys can divide and conquer.
>
> Cheers,
> David
>
>>
>> Jonathan
>>
>>
>> On Nov 18, 2007, at 4:16 PM, David Chelimsky wrote:
>>
>>
>>> Hi everybody.
>>>
>>> Per http://rubyforge.org/pipermail/rspec-users/2007-November/
>>> 004572.html,
>>> we're going to be moving ticket tracking over to lighthouse. We'd  
>>> like
>>> to get this rolling sooner than later, but we're fairly well  
>>> occupied
>>> getting ready for the 1.1 release and writing rspec books :)
>>>
>>> We've got the lighthouse account set up. The thing we need to do to
>>> start using it is to get all the open tickets at rubyforge copied  
>>> over
>>> to lighthouse. As of today, lighthouse does not offer any sort of
>>> automated means of doing that.
>>>
>>> If any of you are interested in helping out by either manually  
>>> copying
>>> tickets over or devising an automated means of doing so, please  
>>> speak
>>> up. It would be a big help to the both the rspec community and the
>>> rspec development team.
>>>
>>> Cheers,
>>> David
>>> _______________________________________________
>>> rspec-users mailing list
>>> rspec-users at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From nathan.sutton at gmail.com  Mon Nov 19 00:42:38 2007
From: nathan.sutton at gmail.com (Nathan Sutton)
Date: Sun, 18 Nov 2007 23:42:38 -0600
Subject: [rspec-devel] [rspec-users] help anyone?
In-Reply-To: <DA40C681-6D8B-4FE0-9D67-68CE011A6CEC@spicycode.com>
References: <57c63afe0711181316l7875bcdcsda1927b9e61f6b0e@mail.gmail.com>
	<C33E9BF7-9B2C-4934-B7D6-C6708E1FFA61@parkerhill.com>
	<57c63afe0711181426m10730239g3b8c7f4c52c390e3@mail.gmail.com>
	<DA40C681-6D8B-4FE0-9D67-68CE011A6CEC@spicycode.com>
Message-ID: <2572F8A6-055D-4F6D-B377-98179D4C0BFB@gmail.com>

Woo, nice work. : )

Nathan Sutton
fowlduck at gmail.com
rspec edge revision 2910
rspec_on_rails edge revision 2909
rails edge revision 8167





On Nov 18, 2007, at 11:41 PM, Chad Humphries wrote:

> David,
>
> The move should be complete now.
>
> -Chad
>
> On Nov 18, 2007, at 5:26 PM, David Chelimsky wrote:
>
>> On Nov 18, 2007 4:16 PM, Jonathan Linowes <jonathan at parkerhill.com>
>> wrote:
>>> David,
>>>
>>> If no one else offers a more efficient solution, I'm willing to
>>> manually copy the open tickets. (I count 37 of them)
>>> I have read access to Rubyforge
>>> and see this as an opportunity to get familiar with lighthouse
>>
>> Thanks Jonathan, but Chad Humpries has already offered to do this (on
>> the rspec-devel list).
>>
>> Also - there are 37 but there are also 9 patches and 77 feature
>> requests. We need them all to get moved over.
>>
>> If you want to coordinate w/ Chad and Scott (who also volunteered),
>> perhaps you guys can divide and conquer.
>>
>> Cheers,
>> David
>>
>>>
>>> Jonathan
>>>
>>>
>>> On Nov 18, 2007, at 4:16 PM, David Chelimsky wrote:
>>>
>>>
>>>> Hi everybody.
>>>>
>>>> Per http://rubyforge.org/pipermail/rspec-users/2007-November/
>>>> 004572.html,
>>>> we're going to be moving ticket tracking over to lighthouse. We'd
>>>> like
>>>> to get this rolling sooner than later, but we're fairly well
>>>> occupied
>>>> getting ready for the 1.1 release and writing rspec books :)
>>>>
>>>> We've got the lighthouse account set up. The thing we need to do to
>>>> start using it is to get all the open tickets at rubyforge copied
>>>> over
>>>> to lighthouse. As of today, lighthouse does not offer any sort of
>>>> automated means of doing that.
>>>>
>>>> If any of you are interested in helping out by either manually
>>>> copying
>>>> tickets over or devising an automated means of doing so, please
>>>> speak
>>>> up. It would be a big help to the both the rspec community and the
>>>> rspec development team.
>>>>
>>>> Cheers,
>>>> David
>>>> _______________________________________________
>>>> rspec-users mailing list
>>>> rspec-users at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>>
>>> _______________________________________________
>>> rspec-users mailing list
>>> rspec-users at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>>
>> _______________________________________________
>> 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 undees at gmail.com  Mon Nov 19 00:44:00 2007
From: undees at gmail.com (Ian Dees)
Date: Sun, 18 Nov 2007 21:44:00 -0800
Subject: [rspec-devel] [ANN] Lighthouse and Engine Yard sponsorships
Message-ID: <ad4f9af90711182144j38a6c02u82e9f61fe588e8ae@mail.gmail.com>

Quoth Nathan:

> How many people do ruby dev on windows?

Lots, I'd wager.

> I sympathize with your
> situation, but if git is superior and few people use windows, yeah...

"If git is superior" is a pretty big if.

From nathan.sutton at gmail.com  Mon Nov 19 00:46:59 2007
From: nathan.sutton at gmail.com (Nathan Sutton)
Date: Sun, 18 Nov 2007 23:46:59 -0600
Subject: [rspec-devel] [ANN] Lighthouse and Engine Yard sponsorships
In-Reply-To: <ad4f9af90711182144j38a6c02u82e9f61fe588e8ae@mail.gmail.com>
References: <ad4f9af90711182144j38a6c02u82e9f61fe588e8ae@mail.gmail.com>
Message-ID: <5E4E2629-2D3D-4A19-9AB2-680680B9C479@gmail.com>

Do you like hg better than git?  or is it what you've learned because  
of platform restrictions?

Nathan Sutton
fowlduck at gmail.com
rspec edge revision 2910
rspec_on_rails edge revision 2909
rails edge revision 8167





On Nov 18, 2007, at 11:44 PM, Ian Dees wrote:

> Quoth Nathan:
>
>> How many people do ruby dev on windows?
>
> Lots, I'd wager.
>
>> I sympathize with your
>> situation, but if git is superior and few people use windows, yeah...
>
> "If git is superior" is a pretty big if.
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From pergesu at gmail.com  Mon Nov 19 01:11:24 2007
From: pergesu at gmail.com (Pat Maddox)
Date: Sun, 18 Nov 2007 22:11:24 -0800
Subject: [rspec-devel] [ANN] Lighthouse and Engine Yard sponsorships
In-Reply-To: <5E4E2629-2D3D-4A19-9AB2-680680B9C479@gmail.com>
References: <ad4f9af90711182144j38a6c02u82e9f61fe588e8ae@mail.gmail.com>
	<5E4E2629-2D3D-4A19-9AB2-680680B9C479@gmail.com>
Message-ID: <810a540e0711182211g21cdb4bboa7f5f5aaedb295c@mail.gmail.com>

On Nov 18, 2007 9:46 PM, Nathan Sutton <nathan.sutton at gmail.com> wrote:
> Do you like hg better than git?  or is it what you've learned because
> of platform restrictions?

I spent a week each with hg and git, doing all of my dev work.  git
wins hands-down.  Then again, I write code in TextMate on a Mac, for
Rails, using RSpec.  So I guess I'm just spoiled with using the best
tools around.

Pat

From psq at nanorails.com  Mon Nov 19 01:24:37 2007
From: psq at nanorails.com (Pascal)
Date: Sun, 18 Nov 2007 22:24:37 -0800
Subject: [rspec-devel] Edge rspec - running Test::Unit tests
In-Reply-To: <57c63afe0711181537n5684b7c3jbcf9f1b8ee4765ce@mail.gmail.com>
References: <66036C9C-37C2-40F7-83FB-642B70CE4DDE@nanorails.com>
	<57c63afe0711180252y71bb35c6jd477757df6868a42@mail.gmail.com>
	<CAA622E5-DA6F-4E29-B895-4C1236E27680@nanorails.com>
	<57c63afe0711181537n5684b7c3jbcf9f1b8ee4765ce@mail.gmail.com>
Message-ID: <E4151405-38BA-4893-B224-DFAD1512C629@nanorails.com>


On Nov 18, 2007, at 3:37 PM, David Chelimsky wrote:

> On Nov 18, 2007 5:31 PM, Pascal <psq at nanorails.com> wrote:
>>
>> On Nov 18, 2007, at 2:52 AM, David Chelimsky wrote:
>>
>>> On Nov 18, 2007 4:47 AM, Pascal <psq at nanorails.com> wrote:
>>>>
>>>> Posted by David Chelimsky (Guest)
>>>> on 14.10.2007 15:54
>>>> On 10/12/07, Alvin Schur <a.schur at nucleus.com> wrote:
>>>>>
>>>>> Finished in 4.5e-05 seconds
>>>>>
>>>>> 0 examples, 0 failures
>>>>>
>>>>>
>>>>> How can I get Test::Unit and rspec to happily co-exist again?
>>>>
>>>> This is due to a refactoring that we're doing. We thought it was
>>>> almost done so we moved it to trunk. We were wrong.
>>>>
>>>> This issue is on the radar and will be addressed before the next
>>>> release.
>>>> I'd be happy to help on this.  Anyone can provide any thoughts on
>>>> how you
>>>> envision implementing it?
>>>
>>> This particular problem has been addressed and we're pretty close  
>>> to a
>>> release at this point. We've (mostly Aslak) started to add stories  
>>> for
>>> T::U integration and this particular problem is already fixed. Feel
>>> free to peek at the trunk and see how the stories are working and if
>>> you have any ideas to add or enhance them.
>>
>> Thanks!
>>
>> I'm still experiencing some issues running trunk (2910) wit rails 2.0
>> (8166), it works when I run an individual test (it runs tests and
>> specs, and report on each one), but not when running rake test:units.
>
> rake test:units is not supported by rspec
>
> You want to use this instead:
>
> rake spec:models
I realize that's what I would need to run the specs on the models,  
which would run things under spec/models.  But what about existing  
test cases under test/...

So are you saying that once you install RSpec (as a plugin), you  
should no longer expect to run your existing test cases?  (This  
appeared to work fine up to 1.0.8 and rewriting 100s of tests will  
take a while, so that's definitely something I'm interested in  
pursuing).

Is this something you are fundamentally opposed to, or would you be  
interested in a patch (assuming I can get this to work)?

Cheers,
Pascal
--
http://blog.nanorails.com

>
>
>> It runs the specs and reports on them, then I get a "rake aborted".
>> I'll investigate later today what the failure is (no useful message
>> displayed).  The problem could be on my side.
>>
>> What's the class running the test cases?  Somewhere in the Runner?
>>
>>
>> Cheers,
>> Pascal.
>> --
>> http://blog.nanorails.com
>>
>>>
>>>
>>> Cheers,
>>> David
>>>
>>>>
>>>> Cheers,
>>>> Pascal.
>>>> --
>>>> http://blog.nanorails.com
>>>> _______________________________________________
>>>> 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


From noreply at rubyforge.org  Mon Nov 19 02:26:40 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Nov 2007 02:26:40 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-15394 ] RSpec website does
	not render correctly with IE6
Message-ID: <20071119072640.4761518585B2@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: Closed
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.)


----------------------------------------------------------------------

>Comment By: David Roberts (deejay)
Date: 2007-11-19 07:26

Message:
Dissappointing that this has been closed without action or 
comment. DJ


----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 02:34

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/44-15394-rspec-website-does-not-render-correctly-with-ie6

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=15394&group_id=797

From win at wincent.com  Mon Nov 19 03:12:34 2007
From: win at wincent.com (Wincent Colaiuta)
Date: Mon, 19 Nov 2007 09:12:34 +0100
Subject: [rspec-devel] [ANN] Lighthouse and Engine Yard sponsorships
In-Reply-To: <mailman.84.1195433591.10081.rspec-devel@rubyforge.org>
References: <mailman.84.1195433591.10081.rspec-devel@rubyforge.org>
Message-ID: <C8B8D6C3-30CA-49FF-A7DA-E6B92FA3101C@wincent.com>

El 19/11/2007, a las 1:53, "Pat Maddox" <pergesu at gmail.com> escribi?:

> On Nov 18, 2007 1:27 PM, Courtenay <court3nay at gmail.com> wrote:
>>
>> Git +1
>> :)
>
> +2 :)


My thoughts exactly. If anyone is interested in hearing why I'd be  
happy to elaborate on this.

Wincent

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2413 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/rspec-devel/attachments/20071119/a52028c6/attachment.bin 

From noreply at rubyforge.org  Mon Nov 19 03:43:54 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Nov 2007 03:43:54 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-12760 ] Autotest regexp no longer
	matches new pretty output
Message-ID: <20071119084354.36EF2185856B@rubyforge.org>

Bugs item #12760, was opened at 2007-08-02 01:29
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12760&group_id=797

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Jay Levitt (jaylev)
Assigned to: Nobody (None)
Summary: Autotest regexp no longer matches new pretty output

Initial Comment:
Aslak changed lib/spec/matchers/operator_matcher.rb in July to be nice and pretty, but lib/autotest/rspec.rb hasn't been updated to match it, so the output from autotest is now just blank lines when a should == expectation fails.

describe "it" do
  it "doesn't work" do
    1.should == 2
  end
end

Windows XP SP2 under cygwin
ruby 1.8.6 [i386-cygwin]
rspec r2189

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 03:59

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/56-12760-autotest-regexp-no-longer-matches-new-pretty-output

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-09-23 20:55

Message:
Is this still a problem?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12760&group_id=797

From noreply at rubyforge.org  Mon Nov 19 03:44:12 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Nov 2007 03:44:12 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-12898 ] render should support :inline
Message-ID: <20071119084412.69A881858570@rubyforge.org>

Bugs item #12898, was opened at 2007-08-08 01:24
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12898&group_id=797

Category: rails plugin
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Jay Levitt (jaylev)
Assigned to: Nobody (None)
Summary: render should support :inline

Initial Comment:
The version of render in rspec_on_rails/lib/rails/dsl/behaviour/view.rb supports only rendering a template, a partial, or a file.  The ability to render :inline would be useful for such things as testing custom FormBuilders, e.g.:

describe LabelledBuilder do

  it "should let me create a text field" do
    object = mock(object)
    object.stub!(:attribute).and_return("Test String")

     render :inline =>
      "<% form_for(@object, :builder => LabelledBuilder) do |f| -%>
        <%= f.text_field :attribute %>
       <% end %>"

     response.should have_tag("label")
  end
end

results in:

Unhandled render type in view spec.



----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 04:00

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/57-12898-render-should-support-inline

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12898&group_id=797

From noreply at rubyforge.org  Mon Nov 19 03:44:56 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Nov 2007 03:44:56 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-12963 ] RESTfully generated
	(polymorphic) helpers require arguments in rspec but not in rails
Message-ID: <20071119084456.C323A185856B@rubyforge.org>

Bugs item #12963, was opened at 2007-08-10 14:01
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12963&group_id=797

Category: rails plugin
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Lance Carlson (lancelot)
Assigned to: Nobody (None)
Summary: RESTfully generated (polymorphic) helpers require arguments in rspec but not in rails

Initial Comment:
My view tests fail when I try to use the polymorphic helpers in rails and report back an error like this:

ActionView::TemplateError in 'Edit Artist Page should render the edit
artist form'
label_artist_url failed to generate from {:controller=>"artists",
:action=>"show"} - you may have ambiguous routes, or you may need to
supply additional parameters for this route.  content_url has the
following required parameters: ["labels", :label_id, "artists", :id] -
are they all satisfied?
On line #3 of app/views/artists/edit.rhtml

   1: <h1>Editing artist</h1>
   2:
   3: <% form_tag label_artist_path, :method => :put do %>
   4:   <%= render :partial => 'form' %>
   5:   <%= submit_tag 'Save' %>
   6: <% end %>

I could stub out the method, but then I wouldn't be testing the view in its entirety. I could provide the arguments that it asks for and the tests passes. Forcing me to add the arguments adds unnecessary noise to the code and should not be a requirement to get tests to pass in rspec. I will try this without nested routes and see if the same problem arises and will also try to see if I can make a patch for this. 

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 04:01

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/58-12963-restfully-generated-polymorphic-helpers-require-arguments-in-rspec-but-not-in-rails

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12963&group_id=797

From noreply at rubyforge.org  Mon Nov 19 03:45:19 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Nov 2007 03:45:19 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-13039 ] exceptions in views give a noisy
	stack trace
Message-ID: <20071119084519.29A5C185856B@rubyforge.org>

Bugs item #13039, was opened at 2007-08-14 01:32
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13039&group_id=797

Category: rails plugin
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Jay Levitt (jaylev)
Assigned to: Nobody (None)
Summary: exceptions in views give a noisy stack trace

Initial Comment:
# spec/views/bad_spec.rb
require File.dirname(__FILE__) + '/../../spec_helper'

describe "test" do
  it "test" do
    m = mock("test")
    assigns[:m] = m
    render '/users/test'
  end
end

# app/views/user/test.html.erb
<% @m.blah %>

Result: The stack trace isn't cleaned by backtrace_tweaker, because instead of e.backtrace being an array of strings, each with one line, it's an array with one element - all the lines of the backtrace concatenated with "\n" separators.

I cannot figure out where this is happening.  The exception as re-raised by ActionView::Base#render_file still has a proper array, but by the time it gets to Spec::DSL::Example#run_example, it's a single-element array.  I don't know enough about exceptions to know how to find every rescue/re-raise of the exception...



----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 04:03

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/59-13039-exceptions-in-views-give-a-noisy-stack-trace#ticket-59-2

----------------------------------------------------------------------

Comment By: Jay Levitt (jaylev)
Date: 2007-08-14 02:06

Message:
OK, a little set_trace_func and now I get it.  When
ActionView::Base#render_file reraises the exception, it's
actually setting the backtrace to template_source, which I
guess must come from ERB, and which is newline-separated. 
However, it changes the exception type to TemplateError, and
stashes the original exception in e.original_exception.

So we could do a few things:

1. Parse the newlines out if this is a TemplateError.
2. Look at e.original_exception.backtrace instead of
e.backtrace if this is a TemplateError.
3. Some combination of the two.  That'd only be necessary if
the two backtraces could ever differ; I have no idea if that
could happen or not.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13039&group_id=797

From noreply at rubyforge.org  Mon Nov 19 03:45:35 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Nov 2007 03:45:35 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-13141 ] backtrace should only be tweaked
	at end, not beginning
Message-ID: <20071119084535.98D85185856B@rubyforge.org>

Bugs item #13141, was opened at 2007-08-16 21:15
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13141&group_id=797

Category: runner module
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Jay Levitt (jaylev)
Assigned to: Nobody (None)
Summary: backtrace should only be tweaked at end, not beginning

Initial Comment:
Imagine this failing view spec:

describe "this spec" do
  it "should fail" do
    form_for(nil,nil){}
  end
end

The output is:

NoMethodError in 'LabelledBuilderHelper providing labelled_form_for should fail'
You have a nil object when you didn't expect it!
You might have expected an instance of Array.
The error occurred while evaluating nil.<<
./spec/helpers/labelled_builder_helper_spec.rb:4:
script/spec:4:

But of course there is no << in line 4 of this spec.  The error happened inside form_for, and thus the error message is tweaked away.

I think tweak_backtrace should only eliminate those matching lines that occur at the end of the backtrace - i.e. the many parent classes of rails.  Ya?


----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 04:05

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/60-13141-backtrace-should-only-be-tweaked-at-end-not-beginning#ticket-60-2

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-21 18:39

Message:
Great. Thanks for playing!

----------------------------------------------------------------------

Comment By: Ryan Bates (ryanb)
Date: 2007-08-21 18:35

Message:
I understand now. Sorry for the confusion. I see there's a separate ticket [#13020] which (I think) covers the problem I am having. I'll post over there.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-21 18:27

Message:
Jay's problem is that the filtered backtrace is lying about the location of the error. The backtrace you posted is a complete backtrace and tells you exactly where to look to debug the problem. Two completely separate issues.

----------------------------------------------------------------------

Comment By: Ryan Bates (ryanb)
Date: 2007-08-21 18:22

Message:
Is this problem unrelated to the backtrace tweaker then? From my understanding that just removes some lines of the backtrace.

Either way, I'm sure my problem is the same as mentioned in this ticket. It's a helper spec and I'm getting the same error message. Here's the full backtrace: http://pastie.caboo.se/89745

I'm on edge rails as you can probably tell. Maybe that is part of the problem?

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-21 17:53

Message:
Ryan - this is a request for a different backtrace, not a full backtrace. You can already get a full backtrace with the -b option.

----------------------------------------------------------------------

Comment By: Ryan Bates (ryanb)
Date: 2007-08-21 17:39

Message:
+1

I'm running into this problem and it makes it very difficult to debug without a full stack trace.


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13141&group_id=797

From noreply at rubyforge.org  Mon Nov 19 03:46:01 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Nov 2007 03:46:01 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-13208 ] Specdoc outputs wrong spec names
	with drbserver
Message-ID: <20071119084601.1426C185856B@rubyforge.org>

Bugs item #13208, was opened at 2007-08-19 21:26
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13208&group_id=797

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 4
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: Specdoc outputs wrong spec names with drbserver

Initial Comment:

In a rails project (trunk, rev. 7345, ruby 1.8.6, Mac OS X, Rspec & rspec on rails frozen in /vendor/plugins at current release, 1.0.8), with the following spec.opts:

--colour

--loadby mtime
--reverse
--drb
--format specdoc

The output looks as follows:

ptolemy# rake spec
(in /Users/smt/src/web/urbis/branches/rails_2.0_integration)

      *******************************************************************
      * config.breakpoint_server has been deprecated and has no effect. *
      *******************************************************************
      

#<DRb::DRbUnknown:0x14e7298>
- should have the unit name
- should have the keyword
- should ensure that each unit_name is unique

#<DRb::DRbUnknown:0x14b4604>
- should add the error 'Wrong category for this item' on validation of the attempt if the goal's category is equal to the item's category (PENDING: Not Yet Implemented)
- should add the error 'Wrong category for this item' on validation of the attempt if the goal's category is nil (PENDING: Not Yet Implemented)


Obviously the class names/description blocks are not being displayed properly.




----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-11-19 04:06

Message:
Moved to http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/61-13208-specdoc-outputs-wrong-spec-names-with-drbserver#ticket-61-2

----------------------------------------------------------------------

Comment By: Chris Scharf (scharfie)
Date: 2007-11-08 19:20

Message:
I believe I have found the fix for this.  In the behaviour.rb file for RSpec (rspec/lib/spec/dsl/behaviour.rb) change the following line in the run method:

  reporter.add_behaviour(@description)

to 

  reporter.add_behaviour(@description.to_s)

----------------------------------------------------------------------

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-08-20 08:43

Message:
This is happening because Behaviour is not serializable. I'll look into this one.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13208&group_id=797

From dchelimsky at gmail.com  Mon Nov 19 04:26:44 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Mon, 19 Nov 2007 03:26:44 -0600
Subject: [rspec-devel] Edge rspec - running Test::Unit tests
In-Reply-To: <E4151405-38BA-4893-B224-DFAD1512C629@nanorails.com>
References: <66036C9C-37C2-40F7-83FB-642B70CE4DDE@nanorails.com>
	<57c63afe0711180252y71bb35c6jd477757df6868a42@mail.gmail.com>
	<CAA622E5-DA6F-4E29-B895-4C1236E27680@nanorails.com>
	<57c63afe0711181537n5684b7c3jbcf9f1b8ee4765ce@mail.gmail.com>
	<E4151405-38BA-4893-B224-DFAD1512C629@nanorails.com>
Message-ID: <57c63afe0711190126j757a01bcr27609630eb38fe27@mail.gmail.com>

On Nov 19, 2007 12:24 AM, Pascal <psq at nanorails.com> wrote:
>
>
> On Nov 18, 2007, at 3:37 PM, David Chelimsky wrote:
>
> > On Nov 18, 2007 5:31 PM, Pascal <psq at nanorails.com> wrote:
> >>
> >> On Nov 18, 2007, at 2:52 AM, David Chelimsky wrote:
> >>
> >>> On Nov 18, 2007 4:47 AM, Pascal <psq at nanorails.com> wrote:
> >>>>
> >>>> Posted by David Chelimsky (Guest)
> >>>> on 14.10.2007 15:54
> >>>> On 10/12/07, Alvin Schur <a.schur at nucleus.com> wrote:
> >>>>>
> >>>>> Finished in 4.5e-05 seconds
> >>>>>
> >>>>> 0 examples, 0 failures
> >>>>>
> >>>>>
> >>>>> How can I get Test::Unit and rspec to happily co-exist again?
> >>>>
> >>>> This is due to a refactoring that we're doing. We thought it was
> >>>> almost done so we moved it to trunk. We were wrong.
> >>>>
> >>>> This issue is on the radar and will be addressed before the next
> >>>> release.
> >>>> I'd be happy to help on this.  Anyone can provide any thoughts on
> >>>> how you
> >>>> envision implementing it?
> >>>
> >>> This particular problem has been addressed and we're pretty close
> >>> to a
> >>> release at this point. We've (mostly Aslak) started to add stories
> >>> for
> >>> T::U integration and this particular problem is already fixed. Feel
> >>> free to peek at the trunk and see how the stories are working and if
> >>> you have any ideas to add or enhance them.
> >>
> >> Thanks!
> >>
> >> I'm still experiencing some issues running trunk (2910) wit rails 2.0
> >> (8166), it works when I run an individual test (it runs tests and
> >> specs, and report on each one), but not when running rake test:units.
> >
> > rake test:units is not supported by rspec
> >
> > You want to use this instead:
> >
> > rake spec:models
> I realize that's what I would need to run the specs on the models,
> which would run things under spec/models.  But what about existing
> test cases under test/...
>
> So are you saying that once you install RSpec (as a plugin), you
> should no longer expect to run your existing test cases?

No - not at all. I misunderstood your situation.

>  (This
> appeared to work fine up to 1.0.8 and rewriting 100s of tests will
> take a while, so that's definitely something I'm interested in
> pursuing).

Naturally!

> Is this something you are fundamentally opposed to, or would you be
> interested in a patch (assuming I can get this to work)?

A patch would be great. We've moved the tracker (which is why your
mailbox has 250 some-odd messages from the rubyforge tracker), so
tickets go to http://rspec.lighthouseapp.com/.

Cheers,
David

>
>
> Cheers,
> Pascal
> --
> http://blog.nanorails.com
>
> >
> >
> >> It runs the specs and reports on them, then I get a "rake aborted".
> >> I'll investigate later today what the failure is (no useful message
> >> displayed).  The problem could be on my side.
> >>
> >> What's the class running the test cases?  Somewhere in the Runner?
> >>
> >>
> >> Cheers,
> >> Pascal.
> >> --
> >> http://blog.nanorails.com
> >>
> >>>
> >>>
> >>> Cheers,
> >>> David
> >>>
> >>>>
> >>>> Cheers,
> >>>> Pascal.
> >>>> --
> >>>> http://blog.nanorails.com
> >>>> _______________________________________________
> >>>> 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
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From dchelimsky at gmail.com  Mon Nov 19 04:29:08 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Mon, 19 Nov 2007 03:29:08 -0600
Subject: [rspec-devel] [ANN] Lighthouse and Engine Yard sponsorships
In-Reply-To: <C8B8D6C3-30CA-49FF-A7DA-E6B92FA3101C@wincent.com>
References: <mailman.84.1195433591.10081.rspec-devel@rubyforge.org>
	<C8B8D6C3-30CA-49FF-A7DA-E6B92FA3101C@wincent.com>
Message-ID: <57c63afe0711190129w5a0681dasf557a182856f4bc2@mail.gmail.com>

On Nov 19, 2007 2:12 AM, Wincent Colaiuta <win at wincent.com> wrote:
> El 19/11/2007, a las 1:53, "Pat Maddox" <pergesu at gmail.com> escribi?:
>
> > On Nov 18, 2007 1:27 PM, Courtenay <court3nay at gmail.com> wrote:
> >>
> >> Git +1
> >> :)
> >
> > +2 :)
>
>
> My thoughts exactly. If anyone is interested in hearing why I'd be
> happy to elaborate on this.

Please.

>
> Wincent
>
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From dchelimsky at gmail.com  Mon Nov 19 04:30:25 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Mon, 19 Nov 2007 03:30:25 -0600
Subject: [rspec-devel] [rspec-users] help anyone?
In-Reply-To: <DA40C681-6D8B-4FE0-9D67-68CE011A6CEC@spicycode.com>
References: <57c63afe0711181316l7875bcdcsda1927b9e61f6b0e@mail.gmail.com>
	<C33E9BF7-9B2C-4934-B7D6-C6708E1FFA61@parkerhill.com>
	<57c63afe0711181426m10730239g3b8c7f4c52c390e3@mail.gmail.com>
	<DA40C681-6D8B-4FE0-9D67-68CE011A6CEC@spicycode.com>
Message-ID: <57c63afe0711190130m78955fe2t92d1268c991458a2@mail.gmail.com>

On Nov 18, 2007 11:41 PM, Chad Humphries <chad at spicycode.com> wrote:
> David,
>
> The move should be complete now.

Thank you, thank you, thank you. Great effort. Much appreciated!

Cheers,
David

>
> -Chad
>
>
> On Nov 18, 2007, at 5:26 PM, David Chelimsky wrote:
>
> > On Nov 18, 2007 4:16 PM, Jonathan Linowes <jonathan at parkerhill.com>
> > wrote:
> >> David,
> >>
> >> If no one else offers a more efficient solution, I'm willing to
> >> manually copy the open tickets. (I count 37 of them)
> >> I have read access to Rubyforge
> >> and see this as an opportunity to get familiar with lighthouse
> >
> > Thanks Jonathan, but Chad Humpries has already offered to do this (on
> > the rspec-devel list).
> >
> > Also - there are 37 but there are also 9 patches and 77 feature
> > requests. We need them all to get moved over.
> >
> > If you want to coordinate w/ Chad and Scott (who also volunteered),
> > perhaps you guys can divide and conquer.
> >
> > Cheers,
> > David
> >
> >>
> >> Jonathan
> >>
> >>
> >> On Nov 18, 2007, at 4:16 PM, David Chelimsky wrote:
> >>
> >>
> >>> Hi everybody.
> >>>
> >>> Per http://rubyforge.org/pipermail/rspec-users/2007-November/
> >>> 004572.html,
> >>> we're going to be moving ticket tracking over to lighthouse. We'd
> >>> like
> >>> to get this rolling sooner than later, but we're fairly well
> >>> occupied
> >>> getting ready for the 1.1 release and writing rspec books :)
> >>>
> >>> We've got the lighthouse account set up. The thing we need to do to
> >>> start using it is to get all the open tickets at rubyforge copied
> >>> over
> >>> to lighthouse. As of today, lighthouse does not offer any sort of
> >>> automated means of doing that.
> >>>
> >>> If any of you are interested in helping out by either manually
> >>> copying
> >>> tickets over or devising an automated means of doing so, please
> >>> speak
> >>> up. It would be a big help to the both the rspec community and the
> >>> rspec development team.
> >>>
> >>> Cheers,
> >>> David
> >>> _______________________________________________
> >>> rspec-users mailing list
> >>> rspec-users at rubyforge.org
> >>> http://rubyforge.org/mailman/listinfo/rspec-users
> >>
> >> _______________________________________________
> >> rspec-users mailing list
> >> rspec-users at rubyforge.org
> >> http://rubyforge.org/mailman/listinfo/rspec-users
> >>
> > _______________________________________________
> > 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  Mon Nov 19 04:37:38 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Mon, 19 Nov 2007 03:37:38 -0600
Subject: [rspec-devel] [ANN] Ticket tracking moved to lighthouse
Message-ID: <57c63afe0711190137y15d237car6f64454428fde53e@mail.gmail.com>

Hi everyone,

We've moved ticket tracking for the rspec project to
http://rspec.lighthouseapp.com! Thanks to a valiant effort from Chad
Humphries, the move was done in an evening.

For those of you on the rspec-devel list, apologies for the wealth of
noise in this process. I set the trackers to stop sending email and
they apparently didn't listen.

For those of you who submitted tickets and were keeping an eye on them
at rubyforge, you'll need to set yourself up as a Watcher on the
ticket. Please go to http://rspec.lighthouseapp.com, search for your
ticket and click on the Watch This Ticket button on your ticket
(you'll need to sign up to do this).

Cheers,
David

From psq at nanorails.com  Mon Nov 19 04:40:44 2007
From: psq at nanorails.com (Pascal)
Date: Mon, 19 Nov 2007 01:40:44 -0800
Subject: [rspec-devel] Edge rspec - running Test::Unit tests
In-Reply-To: <57c63afe0711190126j757a01bcr27609630eb38fe27@mail.gmail.com>
References: <66036C9C-37C2-40F7-83FB-642B70CE4DDE@nanorails.com>
	<57c63afe0711180252y71bb35c6jd477757df6868a42@mail.gmail.com>
	<CAA622E5-DA6F-4E29-B895-4C1236E27680@nanorails.com>
	<57c63afe0711181537n5684b7c3jbcf9f1b8ee4765ce@mail.gmail.com>
	<E4151405-38BA-4893-B224-DFAD1512C629@nanorails.com>
	<57c63afe0711190126j757a01bcr27609630eb38fe27@mail.gmail.com>
Message-ID: <14F92061-884A-46B2-8B2A-B24210A3D524@nanorails.com>

On Nov 19, 2007, at 1:26 AM, David Chelimsky wrote:

> On Nov 19, 2007 12:24 AM, Pascal <psq at nanorails.com> wrote:
>>
>>
>> On Nov 18, 2007, at 3:37 PM, David Chelimsky wrote:
>>
>>> On Nov 18, 2007 5:31 PM, Pascal <psq at nanorails.com> wrote:
>>>>
>>>> On Nov 18, 2007, at 2:52 AM, David Chelimsky wrote:
>>>>
>>>>> On Nov 18, 2007 4:47 AM, Pascal <psq at nanorails.com> wrote:
>>>>>>
>>>>>> Posted by David Chelimsky (Guest)
>>>>>> on 14.10.2007 15:54
>>>>>> On 10/12/07, Alvin Schur <a.schur at nucleus.com> wrote:
>>>>>>>
>>>>>>> Finished in 4.5e-05 seconds
>>>>>>>
>>>>>>> 0 examples, 0 failures
>>>>>>>
>>>>>>>
>>>>>>> How can I get Test::Unit and rspec to happily co-exist again?
>>>>>>
>>>>>> This is due to a refactoring that we're doing. We thought it was
>>>>>> almost done so we moved it to trunk. We were wrong.
>>>>>>
>>>>>> This issue is on the radar and will be addressed before the next
>>>>>> release.
>>>>>> I'd be happy to help on this.  Anyone can provide any thoughts on
>>>>>> how you
>>>>>> envision implementing it?
>>>>>
>>>>> This particular problem has been addressed and we're pretty close
>>>>> to a
>>>>> release at this point. We've (mostly Aslak) started to add stories
>>>>> for
>>>>> T::U integration and this particular problem is already fixed.  
>>>>> Feel
>>>>> free to peek at the trunk and see how the stories are working  
>>>>> and if
>>>>> you have any ideas to add or enhance them.
>>>>
>>>> Thanks!
>>>>
>>>> I'm still experiencing some issues running trunk (2910) wit rails  
>>>> 2.0
>>>> (8166), it works when I run an individual test (it runs tests and
>>>> specs, and report on each one), but not when running rake  
>>>> test:units.
>>>
>>> rake test:units is not supported by rspec
>>>
>>> You want to use this instead:
>>>
>>> rake spec:models
>> I realize that's what I would need to run the specs on the models,
>> which would run things under spec/models.  But what about existing
>> test cases under test/...
>>
>> So are you saying that once you install RSpec (as a plugin), you
>> should no longer expect to run your existing test cases?
>
> No - not at all. I misunderstood your situation.
I could have been clearer...


>
>
>> (This
>> appeared to work fine up to 1.0.8 and rewriting 100s of tests will
>> take a while, so that's definitely something I'm interested in
>> pursuing).
>
> Naturally!
>
>> Is this something you are fundamentally opposed to, or would you be
>> interested in a patch (assuming I can get this to work)?
>
> A patch would be great. We've moved the tracker (which is why your
> mailbox has 250 some-odd messages from the rubyforge tracker), so
> tickets go to http://rspec.lighthouseapp.com/.
Got through those already :)

I'll take a stab at this then.

Cheers,
Pascal.
--
http://blog.nanorails.com


>
>
> Cheers,
> David
>
>>
>>
>> Cheers,
>> Pascal
>> --
>> http://blog.nanorails.com
>>
>>>
>>>
>>>> It runs the specs and reports on them, then I get a "rake aborted".
>>>> I'll investigate later today what the failure is (no useful message
>>>> displayed).  The problem could be on my side.
>>>>
>>>> What's the class running the test cases?  Somewhere in the Runner?
>>>>
>>>>
>>>> Cheers,
>>>> Pascal.
>>>> --
>>>> http://blog.nanorails.com
>>>>
>>>>>
>>>>>
>>>>> Cheers,
>>>>> David
>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>> Pascal.
>>>>>> --
>>>>>> http://blog.nanorails.com
>>>>>> _______________________________________________
>>>>>> 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
>>
>> _______________________________________________
>> 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  Mon Nov 19 06:55:39 2007
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Mon, 19 Nov 2007 12:55:39 +0100
Subject: [rspec-devel] [ANN] Ticket tracking moved to lighthouse
In-Reply-To: <57c63afe0711190137y15d237car6f64454428fde53e@mail.gmail.com>
References: <57c63afe0711190137y15d237car6f64454428fde53e@mail.gmail.com>
Message-ID: <8d961d900711190355s2bac9aebifcf7cea2bdb4ce3c@mail.gmail.com>

We still have to close the existing trackers on Rubyforge and tell
people who go there (and don't read this list) that we're on
lighthouse.

I'll do it tonight unlessyou beat me to it.
Aslak

On 11/19/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> Hi everyone,
>
> We've moved ticket tracking for the rspec project to
> http://rspec.lighthouseapp.com! Thanks to a valiant effort from Chad
> Humphries, the move was done in an evening.
>
> For those of you on the rspec-devel list, apologies for the wealth of
> noise in this process. I set the trackers to stop sending email and
> they apparently didn't listen.
>
> For those of you who submitted tickets and were keeping an eye on them
> at rubyforge, you'll need to set yourself up as a Watcher on the
> ticket. Please go to http://rspec.lighthouseapp.com, search for your
> ticket and click on the Watch This Ticket button on your ticket
> (you'll need to sign up to do this).
>
> Cheers,
> David
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From dchelimsky at gmail.com  Mon Nov 19 07:24:37 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Mon, 19 Nov 2007 06:24:37 -0600
Subject: [rspec-devel] [ANN] Ticket tracking moved to lighthouse
In-Reply-To: <8d961d900711190355s2bac9aebifcf7cea2bdb4ce3c@mail.gmail.com>
References: <57c63afe0711190137y15d237car6f64454428fde53e@mail.gmail.com>
	<8d961d900711190355s2bac9aebifcf7cea2bdb4ce3c@mail.gmail.com>
Message-ID: <57c63afe0711190424m7526977pffcbd17e1ff97490@mail.gmail.com>

On Nov 19, 2007 5:55 AM, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> We still have to close the existing trackers on Rubyforge and tell
> people who go there (and don't read this list) that we're on
> lighthouse.

I don't think there is a way to close them without deleting them
entirely, and I want to keep them around for archival purposes.

I've put notices up on all three trackers about the move:

http://rubyforge.org/tracker/?atid=3149&group_id=797&func=browse

>
> I'll do it tonight unlessyou beat me to it.
> Aslak
>
>
> On 11/19/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> > Hi everyone,
> >
> > We've moved ticket tracking for the rspec project to
> > http://rspec.lighthouseapp.com! Thanks to a valiant effort from Chad
> > Humphries, the move was done in an evening.
> >
> > For those of you on the rspec-devel list, apologies for the wealth of
> > noise in this process. I set the trackers to stop sending email and
> > they apparently didn't listen.
> >
> > For those of you who submitted tickets and were keeping an eye on them
> > at rubyforge, you'll need to set yourself up as a Watcher on the
> > ticket. Please go to http://rspec.lighthouseapp.com, search for your
> > ticket and click on the Watch This Ticket button on your ticket
> > (you'll need to sign up to do this).
> >
> > Cheers,
> > David
> > _______________________________________________
> > 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 win at wincent.com  Mon Nov 19 09:18:59 2007
From: win at wincent.com (Wincent Colaiuta)
Date: Mon, 19 Nov 2007 15:18:59 +0100
Subject: [rspec-devel] Git (was: [ANN] Lighthouse and Engine Yard
	sponsorships)
In-Reply-To: <mailman.50.1195465249.6645.rspec-devel@rubyforge.org>
References: <mailman.50.1195465249.6645.rspec-devel@rubyforge.org>
Message-ID: <EC002555-0795-4D8C-9E00-A4ED18AB5540@wincent.com>

El 19/11/2007, a las 10:40, "David Chelimsky" <dchelimsky at gmail.com>  
escribi?:

> On Nov 19, 2007 2:12 AM, Wincent Colaiuta <win at wincent.com> wrote:
>> El 19/11/2007, a las 1:53, "Pat Maddox" <pergesu at gmail.com> escribi?:
>>
>>> On Nov 18, 2007 1:27 PM, Courtenay <court3nay at gmail.com> wrote:
>>>>
>>>> Git +1
>>>> :)
>>>
>>> +2 :)
>>
>>
>> My thoughts exactly. If anyone is interested in hearing why I'd be
>> happy to elaborate on this.
>
> Please.

I could write a lot about why Git is great in general terms, but I'll  
try to limit myself specifically to areas in which it excels compared  
to the competition (where "the competition" means "other distributed  
SCM systems"; for the purposes of this email I'll take it as a given  
that you're already sold on the proposition that distributed beats  
centralized... explaining why distributed systems are better than  
centralized ones would be a subject for another email: actually, I  
wrote a weblog article on that subject not long ago: see <http://wincent.com/a/about/wincent/weblog/archives/2007/10/why_distributed.php 
 >).

- speed: Git is the fastest system on the block and is getting faster  
all the time due to ongoing "builtin-ification" (replacement of high- 
level "porcelain" scripts with compiled C executables) and ongoing  
optimization. For a repository the size of RSpec's (and probably one  
much larger) all operations are basically instant. You never have to  
wait for Git; Git waits for you. Network transport is very efficient  
too; not only do you generally commit locally (at the speed of light)  
and then push out a batch of changes across the network in one go, but  
the native Git protocol itself is very efficient (although Git also  
knows how to sync over HTTP, rsync, even over email) and repositories  
have extremely small footprints on disk.

- elegance: the underlying model is stunningly simple: four types of  
objects are used to model project history: blobs (file contents),  
trees (collections of files), commits (snapshots of a tree over time  
which are connected to represent history), and tags (annotations on  
commits, that can be used to cryptographically sign a particular  
version of the tree). All of the configuration is in plain text files,  
and all the "crud" is stored in a single ".git" directory at the root  
of the repository. There are no layers of flakey metadata piled on  
top; Git tracks entire trees rather than individual files and so  
doesn't have to worry about tracking file renames and the like (things  
like renames are automatically inferred just by comparing trees which  
are connected in the commit graph; this enables Git to do incredibly  
sophisticated stuff like tracking the movement of a method from one  
file to another).

- robustness: this really flows on from the elegance point: the simple  
design of the system makes it much harder for subtle defects to creep  
into the system. Git really is solid as a rock; there's no black magic  
going on under the hood.

- maturity: Git is currently at version 1.5.3.6 and has been heavily  
used in the trenches on huge projects like the Linux kernel for two  
and a half years now, as well as other big projects like X, Wine and  
others. The "problem" of SCM is basically already solved and you can  
entrust your work to Git with confidence.

- tool set polish: the tool set has a lot of nice little touches which  
you really miss when you have to go back to another SCM (things like  
automatic invocation of the pager when appropriate, and helpful  
colorization of diff, log and other output).

- tool set: Git comes with great cross-platform tools for  
visualization (gitk) preparing commits (git-gui), as well as a number  
of command line tools that you instantly miss when you have to go back  
to svn (things like "git bisect" for locating which commit introduced  
a particular bug; "git stash" for quickly stashing away work, fixing  
something unrelated, and then unstashing what you working on  
previously; "git add --interactive" for staging individual hunks of  
files; "git shortlog" for preparing release notes). Gitweb is a single  
Perl script (easy to install) that comes with Git that provides high- 
quality browser-based navigation of a source repository (or  
repositories).

- optimized, distributed workflow: seeing as RSpec's contributors are  
distributed across the globe, Git's distributed nature makes it a  
great fit. Git has a host of features that make it easy for  
contributors to develop changes in their local repositories and then  
send them "upstream" to the RSpec maintainers. As a couple of  
examples: there is "git-format-patch" for turning a series of changes  
in a patch series (or just a single patch), "git-send-email" for  
sending patches to the rspec-devel mailing list, "git-am" for applying  
said patches, "git-rebase" for bringing a "topic branch" up-to-date  
prior to submitting upstream. If you don't like the email-based  
workflow, there are plenty of other ways to send changes between repos  
using various network transports (either "push" or "pull"). And of  
course, Git has brilliant tools for tracking, visualizing and merging  
these changes. The workflow doesn't just permit collaboration among a  
dispersed group of developers, it's actually optimized for it.  
Branching and merging are ridiculously easy: so much so that "topic  
branches" (short-lived branches created just for the purposes of  
working on a single feature) are the norm. Git has commands for cherry  
picking, history rewriting (this is best used for changes you haven't  
shared with anyone else yet: but I've lost count of the number of  
times I've tweaked the commit I just did using "git commit --amend"),  
and reverting commits (ie. not obliterating a previous change, but  
undoing its effect: this is for published changes where you don't want  
to remove them from the history but you wish to undo their effects; it  
is basically like a "reverse cherry pick").

- extensibility: Git is highly configurable (per repository and per  
user options) and highly extensible (via repository "hooks" which can  
be made to run automatically on checkout, fetch etc); the hooks can be  
used to basically do anything you want; one example that might be  
useful to RSpec is that we could have commits automatically pushed out  
to a Subversion mirror of the Git repository so that users without Git  
installed could still check out the latest version of the source code.

- import: Git should have no problem importing the entire history from  
the Subversion repository.

- community talent: Git had fortunate beginnings in that it was  
written by Linus Torvalds and he's still an active contributor to it,  
so it was immediately adopted in the Linux kernel development process:  
this in itself has attracted a large number of very, very talented  
developers to the project. There are some real "star" contributors in  
the community and I am frequently impressed with their immense  
knowledge and the quality of their patches. As for Linus himself, I  
don't know whether he's a genius or just got lucky, but it seems that  
he had some real visionary insights in the early days when he was  
hacking on Git which shaped its future and made it what it is today  
(particularly things like its approach to modelling repository  
history, its merging philosophy, its whole-tree approach to content  
tracking and so forth); these are details which you don't actually  
need to know about but if you take the time to study them you find  
yourself thankful that Git is the way it is (basically, the way an SCM  
should be; don't know whether I should be surprised that this way of  
doing things didn't become dominant decades ago).

- community process: the development process used by Git itself is a  
real exemplar in the open source world; by observing the patch  
submission and review process (all of which is conducted out in the  
open on the Git mailing list) you can see how Git facilitates  
collaboration among a disconnected group of developers: new features  
are perfected in topic branches to keep them isolated, and as  
development continues on the main line these patch series are  
"rebased" so that they always keep in sync with the head of the main  
line; this avoids unnecessary merges and keeps the history looking  
linear and impressively clear despite the large number of contributors  
to the codebase.

- community innovation: the Git community is relentlessly self- 
improving; I'd say that most of the people working on Git believe that  
it's the best SCM out there (and rightly so, IMO), but despite that  
fact they constantly strive to make it even better than it already is.  
There's a constant focus on improving performance, adding useful  
features, improving the documentation, enhancing usability, and  
smoothing out the initial experience with Git for beginners. To get a  
birds eye view of this process and a sense of Git's momentum, check  
out the latest user survey:

<http://git.or.cz/gitwiki/GitSurvey2007>

And the comparison with the survey from the previous year:

<http://git.or.cz/gitwiki/GitSurvey2006vs2007>

- community activity: since I've been following Git there have been  
maintenance releases roughly every month or few weeks, and feature- 
oriented releases every 2 or 3 months. To date, there are several  
hundred unique authors with code in the official repo. Turn around  
time between reporting a bug and getting a fix into the tree is  
excellent (most bugs nowadays are obscure corner cases; the  
foundations are really, really solid, and test coverage is excellent).

- community responsiveness: building on that last point, Junio Hamano  
is the maintainer and does a wonderful job of showing Git's potential  
for integrating contributions from so many different contributors. The  
mailing list tends to be very helpful with questions, if a little  
perfectionistic in terms of what kinds of patches get accepted into  
the codebase (but that really just shows another strength of Git: it  
makes it really easy to incorporate feedback into works-in-progress,  
rebase to bring things up to date, and then resubmit).

- bright future: Git take-up has really accelerated this year and  
everything indicates that this will only continue. So if you switch to  
Git now you're setting yourself up well for a future time in which  
distributed SCMs become the majority, and among them Git the most  
widely used.

The most oft-cited argument against Git that I've heard is about its  
Windows support. I am not a Windows user myself but I am of the  
understanding that support actually isn't too bad at all. Git is  
officially supported on Windows under the Cygwin environment; a Cygwin- 
less port called MinGW is "very usable" and expected to become part of  
the official distribution in the near future.

Installers can be downloaded from here:

http://code.google.com/p/msysgit/

Don't let the fact that this port isn't yet in the main Git  
distribution deter you: the main contributors to the port are Johannes  
Sixt and Johannes Schindelin who are very active within the Git  
community and it is basically assured that this is what will become  
official in the not too distant future.

More info on Git on Windows is available here:

<http://git.or.cz/gitwiki/WindowsInstall>

The Git mailing list is very responsive too: if you have doubts about  
Git I am sure that if you send a message along the lines of "we are  
project X and we are considering switching to Git, but we'd like to  
resolve our doubts about A, B and C", then you are likely to get some  
pretty helpful replies.

The mailing list info can be found here:

<http://vger.kernel.org/vger-lists.html#git>

Will close with some links. Randal Schwartz (well known author of Perl  
books) gave this Google tech talk on Git (technical):

<http://video.google.es/videoplay?docid=-3999952944619245780>

And Linus sparked a lot of interest in Git earlier this year with this  
flame-y Google talk (not too much technical discussion, mostly high- 
level overview):

<http://video.google.es/videoplay?docid=-2199332044603874737>

There's also this podcast interview with Junio Hamano, the maintainer,  
recorded back in September:

<http://www.twit.tv/floss19>

Cheers,
Wincent



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2413 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/rspec-devel/attachments/20071119/32fcd848/attachment.bin 

From chad at spicycode.com  Mon Nov 19 10:08:20 2007
From: chad at spicycode.com (Chad Humphries)
Date: Mon, 19 Nov 2007 10:08:20 -0500
Subject: [rspec-devel] [ANN] Ticket tracking moved to lighthouse
In-Reply-To: <57c63afe0711190424m7526977pffcbd17e1ff97490@mail.gmail.com>
References: <57c63afe0711190137y15d237car6f64454428fde53e@mail.gmail.com>
	<8d961d900711190355s2bac9aebifcf7cea2bdb4ce3c@mail.gmail.com>
	<57c63afe0711190424m7526977pffcbd17e1ff97490@mail.gmail.com>
Message-ID: <89546E66-E13B-45CF-80E3-6DD5085AC61C@spicycode.com>

I think you can set a flag to block public submissions on them in the  
admin tab.

-Chad

On Nov 19, 2007, at 7:24 AM, David Chelimsky wrote:

> On Nov 19, 2007 5:55 AM, aslak hellesoy <aslak.hellesoy at gmail.com>  
> wrote:
>> We still have to close the existing trackers on Rubyforge and tell
>> people who go there (and don't read this list) that we're on
>> lighthouse.
>
> I don't think there is a way to close them without deleting them
> entirely, and I want to keep them around for archival purposes.
>
> I've put notices up on all three trackers about the move:
>
> http://rubyforge.org/tracker/?atid=3149&group_id=797&func=browse
>
>>
>> I'll do it tonight unlessyou beat me to it.
>> Aslak
>>
>>
>> On 11/19/07, David Chelimsky <dchelimsky at gmail.com> wrote:
>>> Hi everyone,
>>>
>>> We've moved ticket tracking for the rspec project to
>>> http://rspec.lighthouseapp.com! Thanks to a valiant effort from Chad
>>> Humphries, the move was done in an evening.
>>>
>>> For those of you on the rspec-devel list, apologies for the wealth  
>>> of
>>> noise in this process. I set the trackers to stop sending email and
>>> they apparently didn't listen.
>>>
>>> For those of you who submitted tickets and were keeping an eye on  
>>> them
>>> at rubyforge, you'll need to set yourself up as a Watcher on the
>>> ticket. Please go to http://rspec.lighthouseapp.com, search for your
>>> ticket and click on the Watch This Ticket button on your ticket
>>> (you'll need to sign up to do this).
>>>
>>> Cheers,
>>> David
>>> _______________________________________________
>>> 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 lists-rspec at shopwatch.org  Mon Nov 19 12:08:31 2007
From: lists-rspec at shopwatch.org (Jay Levitt)
Date: Mon, 19 Nov 2007 12:08:31 -0500
Subject: [rspec-devel] [ANN] Lighthouse and Engine Yard sponsorships
In-Reply-To: <57c63afe0711181310i7d6c08e2ib6f826221b837af8@mail.gmail.com>
References: <57c63afe0711181310i7d6c08e2ib6f826221b837af8@mail.gmail.com>
Message-ID: <4741C30F.9030106@shopwatch.org>

On 11/18/2007 4:10 PM, David Chelimsky wrote:
> Hey all,
> 
> I'm very happy to announce that ActiveReload[1] has generously offered
> to sponsor a lighthouse[2] account for rspec. We'll be moving ticket
> tracking there. We've already got the account set up and will soon
> make it public.

This is great news - thank you, ActiveReload and EngineYard!

Anyone having trouble registering at Lighthouse?  I tried creating an 
account there, but after it sent me an activation e-mail and I clicked 
the URL, I got "Oops!  You must be a member."

Jay Levitt


From undees at gmail.com  Mon Nov 19 14:41:53 2007
From: undees at gmail.com (Ian Dees)
Date: Mon, 19 Nov 2007 11:41:53 -0800
Subject: [rspec-devel] Git (was: [ANN] Lighthouse and Engine Yard
	sponsorships)
Message-ID: <ad4f9af90711191141m5a479f67t4a0f726424db7637@mail.gmail.com>

Hi, Wincent.

Many things that are good about Git are also good about Mercurial:

> speed

Mercurial performs comparably with Git, and seems even to be faster on Windows.

> elegance

Elegance is hard to define.  Git does indeed have an
easy-to-understand mental model, but so does Mercurial.  Mercurial,
though, also has a simpler command set and is written in clean Python
code (rather than a mishmash of clean C and clean shell scripts).

> robustness

Operations in Mercurial are atomic.  During writes, the metadata is
the last thing to get updated, so you can kill the process in
mid-commit, mid-merge, mid-update, etc., and the source will still be
in a consistent state.  I've brutally stopped commits, tried to shoot
myself in the foot by merging the wrong thing, and so on -- Mercurial
has always rescued me.

> maturity

Mercurial and Git were started at about the same time, for the same
reason (the revocation of the BitKeeper license).

> tool set

Mercurial has hgk, a port of Git's quite nice gitk GUI.  Everything
else I've needed has been abundantly available either as part of the
extensions that ship with Mercurial, or as an easy-to-find Open Source
add-on (kdiff3, TortoiseHg, etc.).  And until there's a "TortoiseGit,"
no one, but no one, will match the TortoiseCVS/TortoiseSVN/TortoiseHg
shell integration for ease of use on Windows.

> optimized, distributed workflow

I think most distributed SCMs have this, by definition.  Offline work,
patch queues, and cherry-picking are par for the course.

> extensibility

I'd have to give Mercurial the win here; in addition to hooks,
Mercurial has an easy extension model and is written in a scripting
language.

> import

I've imported a personal SVN repository into Mercurial without too
much fuss, but I admit it was a simple one -- no branches or merges.

I'll cede you the points on community talent (Linus) and community
activity (bustling).  "Bright future," I dunno.  I hope both projects
have that.

> The most oft-cited argument against Git that I've heard is about its
> Windows support.

And the most oft-cited argument against living underwater is that it's
hard to hold your breath for a long time.  It's oft-cited for a
reason.  ;-)

Lack of Windows support is one common objection, but by no means the
only one.  The complicated interface (I'm just talking command-line
here) is another, as is the hodgepodge of implementation languages and
the perceived abrasiveness of (some of) its supporters.

> Git is officially supported on Windows under the Cygwin environment;

... which is another way of saying "Git isn't officially supported on
Windows."  Requiring end users to jump through all the hoops of
installing Cygwin and making them use bash (though I quite like both
myself) would make Git an absolute non-starter if I tried to push it
in my shop.  I'm glad to hear they're working on it, but Mercurial is
ready now.

> And Linus sparked a lot of interest in Git earlier this year with this
> flame-y Google talk (not too much technical discussion, mostly high-
> level overview):

Actually, that Linus talk was the one that convinced me to go to
Mercurial (which, as he notes in the talk, is the only other SCM he
considers a worthy alternative to Git).

Ultimately, it's not a slam-dunk for Git or Mercurial; RSpec could
probably do fine with either.  But I know which one I'd rather use,
and that's the one that gives me joy on a daily basis.

--Ian

From philodespotos at gmail.com  Mon Nov 19 20:12:12 2007
From: philodespotos at gmail.com (Kyle Hargraves)
Date: Mon, 19 Nov 2007 19:12:12 -0600
Subject: [rspec-devel] Git (was: [ANN] Lighthouse and Engine Yard
	sponsorships)
In-Reply-To: <ad4f9af90711191141m5a479f67t4a0f726424db7637@mail.gmail.com>
References: <ad4f9af90711191141m5a479f67t4a0f726424db7637@mail.gmail.com>
Message-ID: <60f3810c0711191712l3da7831dn7938a87582c6b6d@mail.gmail.com>

On Nov 19, 2007 1:41 PM, Ian Dees <undees at gmail.com> wrote:
> Hi, Wincent.
>
> Many things that are good about Git are also good about Mercurial:

This is very true.

I fairly recently made the switch to git from hg, solely because of
the amazing branching support. With hg, I was ending up with lots of
cluttered directories with a number of cloned repos named
project_foo_feature, project_bar_feature, etc. Topic branches, as
Wincent mentioned, are just a natural part of development in git, and
it's made me a lot more productive. I can easily tuck away changes
that I'm not ready for others to see, I can stash what I was working
on so I can fix a quick 5 minute bug, I can quickly and easily edit my
past commits that I haven't pushed yet, etc.

This took me a few days to pick up, but now I really, really like the
fluidity of it.

However, beyond that, especially if that sort of feature isn't all
that enticing to the people doing the heavy lifting on rspec,
mercurial is just as good of a choice. I've been using it for about a
year and a half and have nothing but praise for it.

I think most of us who advocate distributed systems would be very
happy with either choice.

Kyle

From philodespotos at gmail.com  Mon Nov 19 20:19:22 2007
From: philodespotos at gmail.com (Kyle Hargraves)
Date: Mon, 19 Nov 2007 19:19:22 -0600
Subject: [rspec-devel] Git (was: [ANN] Lighthouse and Engine Yard
	sponsorships)
In-Reply-To: <60f3810c0711191712l3da7831dn7938a87582c6b6d@mail.gmail.com>
References: <ad4f9af90711191141m5a479f67t4a0f726424db7637@mail.gmail.com>
	<60f3810c0711191712l3da7831dn7938a87582c6b6d@mail.gmail.com>
Message-ID: <60f3810c0711191719w5312a0a5yb54e3e9c38d403ca@mail.gmail.com>

On Nov 19, 2007 7:12 PM, Kyle Hargraves <philodespotos at gmail.com> wrote:
> it's made me a lot more productive. I can easily tuck away changes
> that I'm not ready for others to see, I can stash what I was working
> on so I can fix a quick 5 minute bug, I can quickly and easily edit my
> past commits that I haven't pushed yet, etc.

I should mention that a lot of this is possible with hg's patch
queues, so the people inclined to work in that fashion would still be
able to do so using mercurial. It's not quite as natural, as managing
repos for branches can be a hassle, but I happily used it until I
switched to git.

Kyle

From brian.takita at gmail.com  Tue Nov 20 14:33:40 2007
From: brian.takita at gmail.com (Brian Takita)
Date: Tue, 20 Nov 2007 11:33:40 -0800
Subject: [rspec-devel] Do we need more Matcher documentation? Do we need
	Matcher DSL?
Message-ID: <1d7ddd110711201133l4675b742sa3534cf6a269af06@mail.gmail.com>

At the work watercooler, one of my coworkers told me that he had a
difficult time learning how to use matchers.
The use case is, I'm in a hurry and I want to have a custom matcher. I
just want it to work. How do I do it?

The general template of the matchers is a great general purpose
pattern, but is a little daunting.
Are there ways to make it easier to learn?

From dchelimsky at gmail.com  Tue Nov 20 14:39:53 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 20 Nov 2007 13:39:53 -0600
Subject: [rspec-devel] Do we need more Matcher documentation? Do we need
	Matcher DSL?
In-Reply-To: <1d7ddd110711201133l4675b742sa3534cf6a269af06@mail.gmail.com>
References: <1d7ddd110711201133l4675b742sa3534cf6a269af06@mail.gmail.com>
Message-ID: <57c63afe0711201139u13bc3adt73010a4e1b2832be@mail.gmail.com>

On Nov 20, 2007 1:33 PM, Brian Takita <brian.takita at gmail.com> wrote:
> At the work watercooler, one of my coworkers told me that he had a
> difficult time learning how to use matchers.
> The use case is, I'm in a hurry and I want to have a custom matcher. I
> just want it to work. How do I do it?
>
> The general template of the matchers is a great general purpose
> pattern, but is a little daunting.
> Are there ways to make it easier to learn?

There is a poorly documented SimpleMatcher that lets you do limited
things in a hurry.

I think in the end it's just docs. Besides SimpleMatcher and maybe
additional wrappers similar to it, I really don't want to supply a
base matcher because I don't want matchers to be directly coupled to
the rest of rspec. That's part of the beauty of it in my view.

So we should definitely doc things better.

> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From ben at benmabey.com  Tue Nov 20 21:40:04 2007
From: ben at benmabey.com (Ben Mabey)
Date: Tue, 20 Nov 2007 19:40:04 -0700
Subject: [rspec-devel] Failing specs in trunk
Message-ID: <47439A84.7030502@benmabey.com>

Hi all,
When I check out the latest rspec and run the specs I get three failing 
specs.  Are these errors due to my environment not being set up 
correctly?  I have installed all of the gems listed in the README.  I'm 
running Ruby 1.85 patchlevel 2, on OSx leopard.  Below are the summary 
of the errors I am getting:

1)
NoMethodError in 'ExampleGroupMethods should pass before, after, and 
Examples to all ExampleGroup subclasses'
undefined method `before_all_parts' for 
Spec::Example::ExampleGroupMethods:Module
./spec/spec/example/example_group_methods_spec.rb:13:

2)
'HtmlFormatter should produce HTML identical to the one we designed 
manually with --diff' FAILED
........
./spec/spec/runner/formatter/html_formatter_spec.rb:45:in `it - should 
produce HTML identical to the one we designed manually with --diff'
./spec/spec/runner/formatter/html_formatter_spec.rb:20:in `chdir'
./spec/spec/runner/formatter/html_formatter_spec.rb:20:in `it - should 
produce HTML identical to the one we designed manually with --diff'

3)
RuntimeError in 'Spec::Runner::Formatter::TextMateFormatter functional 
spec using --diff should produce HTML identical to the one we designed 
manually with --diff'
There is no HTML file with expected content for this platform: 
./spec/spec/runner/formatter/text_mate_formatted-1.8.5.html
./spec/spec/runner/formatter/spec_mate_formatter_spec.rb:72:in `it - 
should produce HTML identical to the one we designed manually with --diff'
./spec/spec/runner/formatter/spec_mate_formatter_spec.rb:37:in 
`produces_html_identical_to_manually_designed_document'
./spec/spec/runner/formatter/spec_mate_formatter_spec.rb:22:in `chdir'
./spec/spec/runner/formatter/spec_mate_formatter_spec.rb:22:in 
`produces_html_identical_to_manually_designed_document'
./spec/spec/runner/formatter/spec_mate_formatter_spec.rb:68:in `it - 
should produce HTML identical to the one we designed manually with --diff'


I'd like to try and do a patch or two, but would like to see all green 
before I do that. 

Thanks,
Ben

From dchelimsky at gmail.com  Tue Nov 20 21:52:55 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 20 Nov 2007 20:52:55 -0600
Subject: [rspec-devel] Failing specs in trunk
In-Reply-To: <47439A84.7030502@benmabey.com>
References: <47439A84.7030502@benmabey.com>
Message-ID: <57c63afe0711201852ge8a5d54rf937280d4223ffae@mail.gmail.com>

On Nov 20, 2007 8:40 PM, Ben Mabey <ben at benmabey.com> wrote:
> Hi all,
> When I check out the latest rspec

"the latest rspec" changes all the time. Please reference specific
revision numbers when you're talking about trunk.

That said - rev 2829 is broken. I'm working on it now.

> and run the specs I get three failing
> specs.  Are these errors due to my environment not being set up
> correctly?  I have installed all of the gems listed in the README.  I'm
> running Ruby 1.85 patchlevel 2, on OSx leopard.  Below are the summary
> of the errors I am getting:
>
> 1)
> NoMethodError in 'ExampleGroupMethods should pass before, after, and
> Examples to all ExampleGroup subclasses'
> undefined method `before_all_parts' for
> Spec::Example::ExampleGroupMethods:Module
> ./spec/spec/example/example_group_methods_spec.rb:13:
>
> 2)
> 'HtmlFormatter should produce HTML identical to the one we designed
> manually with --diff' FAILED
> ........
> ./spec/spec/runner/formatter/html_formatter_spec.rb:45:in `it - should
> produce HTML identical to the one we designed manually with --diff'
> ./spec/spec/runner/formatter/html_formatter_spec.rb:20:in `chdir'
> ./spec/spec/runner/formatter/html_formatter_spec.rb:20:in `it - should
> produce HTML identical to the one we designed manually with --diff'
>
> 3)
> RuntimeError in 'Spec::Runner::Formatter::TextMateFormatter functional
> spec using --diff should produce HTML identical to the one we designed
> manually with --diff'
> There is no HTML file with expected content for this platform:
> ./spec/spec/runner/formatter/text_mate_formatted-1.8.5.html
> ./spec/spec/runner/formatter/spec_mate_formatter_spec.rb:72:in `it -
> should produce HTML identical to the one we designed manually with --diff'
> ./spec/spec/runner/formatter/spec_mate_formatter_spec.rb:37:in
> `produces_html_identical_to_manually_designed_document'
> ./spec/spec/runner/formatter/spec_mate_formatter_spec.rb:22:in `chdir'
> ./spec/spec/runner/formatter/spec_mate_formatter_spec.rb:22:in
> `produces_html_identical_to_manually_designed_document'
> ./spec/spec/runner/formatter/spec_mate_formatter_spec.rb:68:in `it -
> should produce HTML identical to the one we designed manually with --diff'
>
>
> I'd like to try and do a patch or two, but would like to see all green
> before I do that.
>
> Thanks,
> Ben
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From nathan.sutton at gmail.com  Tue Nov 20 22:12:03 2007
From: nathan.sutton at gmail.com (Nathan Sutton)
Date: Tue, 20 Nov 2007 21:12:03 -0600
Subject: [rspec-devel] Failing specs in trunk
In-Reply-To: <57c63afe0711201852ge8a5d54rf937280d4223ffae@mail.gmail.com>
References: <47439A84.7030502@benmabey.com>
	<57c63afe0711201852ge8a5d54rf937280d4223ffae@mail.gmail.com>
Message-ID: <13182ADC-73A8-4F62-A5BE-B780366E7094@gmail.com>

Cool, please let us know, thanks. :)

Nathan Sutton
fowlduck at gmail.com
rspec edge revision 2910
rspec_on_rails edge revision 2909
rails edge revision 8175



On Nov 20, 2007, at 8:52 PM, David Chelimsky wrote:

> On Nov 20, 2007 8:40 PM, Ben Mabey <ben at benmabey.com> wrote:
>> Hi all,
>> When I check out the latest rspec
>
> "the latest rspec" changes all the time. Please reference specific
> revision numbers when you're talking about trunk.
>
> That said - rev 2829 is broken. I'm working on it now.
>
>> and run the specs I get three failing
>> specs.  Are these errors due to my environment not being set up
>> correctly?  I have installed all of the gems listed in the README.   
>> I'm
>> running Ruby 1.85 patchlevel 2, on OSx leopard.  Below are the  
>> summary
>> of the errors I am getting:
>>
>> 1)
>> NoMethodError in 'ExampleGroupMethods should pass before, after, and
>> Examples to all ExampleGroup subclasses'
>> undefined method `before_all_parts' for
>> Spec::Example::ExampleGroupMethods:Module
>> ./spec/spec/example/example_group_methods_spec.rb:13:
>>
>> 2)
>> 'HtmlFormatter should produce HTML identical to the one we designed
>> manually with --diff' FAILED
>> ........
>> ./spec/spec/runner/formatter/html_formatter_spec.rb:45:in `it -  
>> should
>> produce HTML identical to the one we designed manually with --diff'
>> ./spec/spec/runner/formatter/html_formatter_spec.rb:20:in `chdir'
>> ./spec/spec/runner/formatter/html_formatter_spec.rb:20:in `it -  
>> should
>> produce HTML identical to the one we designed manually with --diff'
>>
>> 3)
>> RuntimeError in 'Spec::Runner::Formatter::TextMateFormatter  
>> functional
>> spec using --diff should produce HTML identical to the one we  
>> designed
>> manually with --diff'
>> There is no HTML file with expected content for this platform:
>> ./spec/spec/runner/formatter/text_mate_formatted-1.8.5.html
>> ./spec/spec/runner/formatter/spec_mate_formatter_spec.rb:72:in `it -
>> should produce HTML identical to the one we designed manually with  
>> --diff'
>> ./spec/spec/runner/formatter/spec_mate_formatter_spec.rb:37:in
>> `produces_html_identical_to_manually_designed_document'
>> ./spec/spec/runner/formatter/spec_mate_formatter_spec.rb:22:in  
>> `chdir'
>> ./spec/spec/runner/formatter/spec_mate_formatter_spec.rb:22:in
>> `produces_html_identical_to_manually_designed_document'
>> ./spec/spec/runner/formatter/spec_mate_formatter_spec.rb:68:in `it -
>> should produce HTML identical to the one we designed manually with  
>> --diff'
>>
>>
>> I'd like to try and do a patch or two, but would like to see all  
>> green
>> before I do that.
>>
>> Thanks,
>> Ben
>> _______________________________________________
>> 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 20 22:17:56 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 20 Nov 2007 21:17:56 -0600
Subject: [rspec-devel] Failing specs in trunk
In-Reply-To: <13182ADC-73A8-4F62-A5BE-B780366E7094@gmail.com>
References: <47439A84.7030502@benmabey.com>
	<57c63afe0711201852ge8a5d54rf937280d4223ffae@mail.gmail.com>
	<13182ADC-73A8-4F62-A5BE-B780366E7094@gmail.com>
Message-ID: <57c63afe0711201917r777b0164s68e1c5b043ba9784@mail.gmail.com>

On Nov 20, 2007 9:12 PM, Nathan Sutton <nathan.sutton at gmail.com> wrote:
> Cool, please let us know, thanks. :)

Sure - it's the specs that are broken - not necessarily rspec itself.

The problem is that there were new examples committed by someone who
is working in Ruby 1.8.5. The examples were calling
ExampleGroupMethods.before_all_parts, which is a method defined in the
ExampleGroupMethods module. From what I can tell, this is not legal
ruby in 1.8.6:

>> module Foo
>> def bar
>> end
>> end
=> nil
>> Foo.bar
NoMethodError: undefined method `bar' for Foo:Module
	from (irb):5

I can only assume that it IS legal in 1.8.5 or they wouldn't have been
committed! Can someone w/ 1.8.5 handy verify for that for me please?

>
> Nathan Sutton
> fowlduck at gmail.com
> rspec edge revision 2910
> rspec_on_rails edge revision 2909
> rails edge revision 8175
>
>
>
>
> On Nov 20, 2007, at 8:52 PM, David Chelimsky wrote:
>
> > On Nov 20, 2007 8:40 PM, Ben Mabey <ben at benmabey.com> wrote:
> >> Hi all,
> >> When I check out the latest rspec
> >
> > "the latest rspec" changes all the time. Please reference specific
> > revision numbers when you're talking about trunk.
> >
> > That said - rev 2829 is broken. I'm working on it now.
> >
> >> and run the specs I get three failing
> >> specs.  Are these errors due to my environment not being set up
> >> correctly?  I have installed all of the gems listed in the README.
> >> I'm
> >> running Ruby 1.85 patchlevel 2, on OSx leopard.  Below are the
> >> summary
> >> of the errors I am getting:
> >>
> >> 1)
> >> NoMethodError in 'ExampleGroupMethods should pass before, after, and
> >> Examples to all ExampleGroup subclasses'
> >> undefined method `before_all_parts' for
> >> Spec::Example::ExampleGroupMethods:Module
> >> ./spec/spec/example/example_group_methods_spec.rb:13:
> >>
> >> 2)
> >> 'HtmlFormatter should produce HTML identical to the one we designed
> >> manually with --diff' FAILED
> >> ........
> >> ./spec/spec/runner/formatter/html_formatter_spec.rb:45:in `it -
> >> should
> >> produce HTML identical to the one we designed manually with --diff'
> >> ./spec/spec/runner/formatter/html_formatter_spec.rb:20:in `chdir'
> >> ./spec/spec/runner/formatter/html_formatter_spec.rb:20:in `it -
> >> should
> >> produce HTML identical to the one we designed manually with --diff'
> >>
> >> 3)
> >> RuntimeError in 'Spec::Runner::Formatter::TextMateFormatter
> >> functional
> >> spec using --diff should produce HTML identical to the one we
> >> designed
> >> manually with --diff'
> >> There is no HTML file with expected content for this platform:
> >> ./spec/spec/runner/formatter/text_mate_formatted-1.8.5.html
> >> ./spec/spec/runner/formatter/spec_mate_formatter_spec.rb:72:in `it -
> >> should produce HTML identical to the one we designed manually with
> >> --diff'
> >> ./spec/spec/runner/formatter/spec_mate_formatter_spec.rb:37:in
> >> `produces_html_identical_to_manually_designed_document'
> >> ./spec/spec/runner/formatter/spec_mate_formatter_spec.rb:22:in
> >> `chdir'
> >> ./spec/spec/runner/formatter/spec_mate_formatter_spec.rb:22:in
> >> `produces_html_identical_to_manually_designed_document'
> >> ./spec/spec/runner/formatter/spec_mate_formatter_spec.rb:68:in `it -
> >> should produce HTML identical to the one we designed manually with
> >> --diff'
> >>
> >>
> >> I'd like to try and do a patch or two, but would like to see all
> >> green
> >> before I do that.
> >>
> >> Thanks,
> >> Ben
> >> _______________________________________________
> >> 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 ben at benmabey.com  Tue Nov 20 22:24:49 2007
From: ben at benmabey.com (Ben Mabey)
Date: Tue, 20 Nov 2007 20:24:49 -0700
Subject: [rspec-devel] Failing specs in trunk
In-Reply-To: <57c63afe0711201917r777b0164s68e1c5b043ba9784@mail.gmail.com>
References: <47439A84.7030502@benmabey.com>	<57c63afe0711201852ge8a5d54rf937280d4223ffae@mail.gmail.com>	<13182ADC-73A8-4F62-A5BE-B780366E7094@gmail.com>
	<57c63afe0711201917r777b0164s68e1c5b043ba9784@mail.gmail.com>
Message-ID: <4743A501.8040004@benmabey.com>

bmabey at mercedes:~/$ruby -v
ruby 1.8.5 (2006-12-04 patchlevel 2) [i686-darwin8.10.1]

 >> module Foo
 >> def bar
 >> end
 >> end
=> nil
 >> Foo.bar
NoMethodError: undefined method `bar' for Foo:Module
        from (irb):5

Doesn't seem to be...

-Ben


David Chelimsky wrote:
> On Nov 20, 2007 9:12 PM, Nathan Sutton <nathan.sutton at gmail.com> wrote:
>   
>> Cool, please let us know, thanks. :)
>>     
>
> Sure - it's the specs that are broken - not necessarily rspec itself.
>
> The problem is that there were new examples committed by someone who
> is working in Ruby 1.8.5. The examples were calling
> ExampleGroupMethods.before_all_parts, which is a method defined in the
> ExampleGroupMethods module. From what I can tell, this is not legal
> ruby in 1.8.6:
>
>   
>>> module Foo
>>> def bar
>>> end
>>> end
>>>       
> => nil
>   
>>> Foo.bar
>>>       
> NoMethodError: undefined method `bar' for Foo:Module
> 	from (irb):5
>
> I can only assume that it IS legal in 1.8.5 or they wouldn't have been
> committed! Can someone w/ 1.8.5 handy verify for that for me please?
>
>   
>> Nathan Sutton
>> fowlduck at gmail.com
>> rspec edge revision 2910
>> rspec_on_rails edge revision 2909
>> rails edge revision 8175
>>
>>
>>
>>
>> On Nov 20, 2007, at 8:52 PM, David Chelimsky wrote:
>>
>>     
>>> On Nov 20, 2007 8:40 PM, Ben Mabey <ben at benmabey.com> wrote:
>>>       
>>>> Hi all,
>>>> When I check out the latest rspec
>>>>         
>>> "the latest rspec" changes all the time. Please reference specific
>>> revision numbers when you're talking about trunk.
>>>
>>> That said - rev 2829 is broken. I'm working on it now.
>>>
>>>       
>>>> and run the specs I get three failing
>>>> specs.  Are these errors due to my environment not being set up
>>>> correctly?  I have installed all of the gems listed in the README.
>>>> I'm
>>>> running Ruby 1.85 patchlevel 2, on OSx leopard.  Below are the
>>>> summary
>>>> of the errors I am getting:
>>>>
>>>> 1)
>>>> NoMethodError in 'ExampleGroupMethods should pass before, after, and
>>>> Examples to all ExampleGroup subclasses'
>>>> undefined method `before_all_parts' for
>>>> Spec::Example::ExampleGroupMethods:Module
>>>> ./spec/spec/example/example_group_methods_spec.rb:13:
>>>>
>>>> 2)
>>>> 'HtmlFormatter should produce HTML identical to the one we designed
>>>> manually with --diff' FAILED
>>>> ........
>>>> ./spec/spec/runner/formatter/html_formatter_spec.rb:45:in `it -
>>>> should
>>>> produce HTML identical to the one we designed manually with --diff'
>>>> ./spec/spec/runner/formatter/html_formatter_spec.rb:20:in `chdir'
>>>> ./spe