From matt-lists at reprocessed.org  Tue Jan  5 07:17:44 2010
From: matt-lists at reprocessed.org (Matt Patterson)
Date: Tue, 5 Jan 2010 12:17:44 +0000
Subject: [rspec-devel] [rspec-users] describe "RSpec's documentation" do
In-Reply-To: <98A6AC6B-BECC-4564-AF04-C49429AC7C75@mattwynne.net>
References: <A3756A49-A10C-4138-8665-AAB730556A2B@gmail.com>
	<98A6AC6B-BECC-4564-AF04-C49429AC7C75@mattwynne.net>
Message-ID: <C6507183-6C14-41D1-8BB0-E0BF67FB63BF@reprocessed.org>

On 9 Nov 2009, at 22:03, Matt Wynne wrote:

> 
> On 6 Nov 2009, at 12:49, David Chelimsky wrote:
> 
>> In the long run, what I'd like is the following:
>> 
>> * Cucumber features that ship with RSpec become the authoritative end-user documentation. This is something that anybody can contribute to with patches, as it's all in files that ship with RSpec. I'd also like to use such an effort to push the envelope on Cucumber features as executable documentation. I think that with a little bit of work we could use the features to generate a website with meaningful organization/navigation. Is anybody already doing that?
> 
> +1
> 
> I had a little epiphany working on the wire protocol feature for cucumber[3]. We were trying to design the protocol via email and lighthouse ticket discussion, started using a wiki to document the desired protocol when I realised - why don't we just use the features!? I would like to see more people pushing Cucumber in this direction, and I think it would be interesting to consider adding mark-up to comments to allow us to build RDoc-style websites from a features folder.

I've been looking at the documentation again recently, and I'd be happy to start work on this, particularly if Matt W is wanting to look at the cucumber end since he's just up the road from me.

I'm very keen on the executable documentation aspects of this, and I did a whole load of work back in 2008 on this kind of stuff using RSpec, so I've got a bit of history here :-)

Matt


-- 
  Matt Patterson | Design & Code
  <matt at reprocessed org> | http://www.reprocessed.org/




From matt-lists at reprocessed.org  Tue Jan  5 08:50:37 2010
From: matt-lists at reprocessed.org (Matt Patterson)
Date: Tue, 5 Jan 2010 13:50:37 +0000
Subject: [rspec-devel] ticket #921: "Fix for git.rb to make Rakefile work"
Message-ID: <5E6DD9EA-0DB1-4D62-8C87-DFE85F8C617A@reprocessed.org>

I've just had a look at this because I got bitten by Rake raising an error before running any tasks in rspec-dev when I nuked my repositories and re-forked because I was so out of date.

https://rspec.lighthouseapp.com/projects/5645-rspec/tickets/921-fix-for-gitrb-to-make-rakefile-work

I thought that the intent behind the raise was to communicate exactly which repos were missing, so I added a topic branch and committed a fix which returned true/false but also wrote to $stderr when a repo was missing.

That's all fine, but I now notice that all_repos_clean? checks you're on the master branch. Is this needed in all cases? In this instance, I was hoping to keep rspec-dev on my topic branch so I didn't pollute my local master branch. As it stands, I would need to either merge in my topic branch to master or revert to master as-is. Rake would error on the latter option, and the first option is undesirable (to me at least) in the hope of keeping it easy to merge upstream changes in.

Is the check for master needed? Is it maybe only needed in certain circumstances?

Matt

-- 
  Matt Patterson | Design & Code
  <matt at reprocessed org> | http://www.reprocessed.org/




From dchelimsky at gmail.com  Tue Jan  5 11:01:29 2010
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 5 Jan 2010 10:01:29 -0600
Subject: [rspec-devel] [rspec-users] describe "RSpec's documentation" do
In-Reply-To: <C6507183-6C14-41D1-8BB0-E0BF67FB63BF@reprocessed.org>
References: <A3756A49-A10C-4138-8665-AAB730556A2B@gmail.com>
	<98A6AC6B-BECC-4564-AF04-C49429AC7C75@mattwynne.net>
	<C6507183-6C14-41D1-8BB0-E0BF67FB63BF@reprocessed.org>
Message-ID: <57c63afe1001050801g2a5a11aega61f7bbd47e9a4b2@mail.gmail.com>

On Tue, Jan 5, 2010 at 6:17 AM, Matt Patterson
<matt-lists at reprocessed.org>wrote:

> On 9 Nov 2009, at 22:03, Matt Wynne wrote:
>
> >
> > On 6 Nov 2009, at 12:49, David Chelimsky wrote:
> >
> >> In the long run, what I'd like is the following:
> >>
> >> * Cucumber features that ship with RSpec become the authoritative
> end-user documentation. This is something that anybody can contribute to
> with patches, as it's all in files that ship with RSpec. I'd also like to
> use such an effort to push the envelope on Cucumber features as executable
> documentation. I think that with a little bit of work we could use the
> features to generate a website with meaningful organization/navigation. Is
> anybody already doing that?
> >
> > +1
> >
> > I had a little epiphany working on the wire protocol feature for
> cucumber[3]. We were trying to design the protocol via email and lighthouse
> ticket discussion, started using a wiki to document the desired protocol
> when I realised - why don't we just use the features!? I would like to see
> more people pushing Cucumber in this direction, and I think it would be
> interesting to consider adding mark-up to comments to allow us to build
> RDoc-style websites from a features folder.
>
> I've been looking at the documentation again recently, and I'd be happy to
> start work on this, particularly if Matt W is wanting to look at the
> cucumber end since he's just up the road from me.
>
> I'm very keen on the executable documentation aspects of this, and I did a
> whole load of work back in 2008 on this kind of stuff using RSpec, so I've
> got a bit of history here :-)
>

Hi Matt,

You mean you want to work on cukes for RSpec? If so, that would be great!

Cheers,
David

Matt
>
>
> --
>  Matt Patterson | Design & Code
>  <matt at reprocessed org> | http://www.reprocessed.org/
>
>
>
> _______________________________________________
> 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/20100105/d60073ff/attachment.html>

From dchelimsky at gmail.com  Tue Jan  5 11:22:20 2010
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 5 Jan 2010 10:22:20 -0600
Subject: [rspec-devel] ticket #921: "Fix for git.rb to make Rakefile
	work"
In-Reply-To: <5E6DD9EA-0DB1-4D62-8C87-DFE85F8C617A@reprocessed.org>
References: <5E6DD9EA-0DB1-4D62-8C87-DFE85F8C617A@reprocessed.org>
Message-ID: <57c63afe1001050822l5f90fb56m4cd02a7c1fcae2a6@mail.gmail.com>

On Tue, Jan 5, 2010 at 7:50 AM, Matt Patterson
<matt-lists at reprocessed.org>wrote:

> I've just had a look at this because I got bitten by Rake raising an error
> before running any tasks in rspec-dev when I nuked my repositories and
> re-forked because I was so out of date.
>
>
> https://rspec.lighthouseapp.com/projects/5645-rspec/tickets/921-fix-for-gitrb-to-make-rakefile-work
>
> I thought that the intent behind the raise was to communicate exactly which
> repos were missing, so I added a topic branch and committed a fix which
> returned true/false but also wrote to $stderr when a repo was missing.
>
> That's all fine, but I now notice that all_repos_clean? checks you're on
> the master branch. Is this needed in all cases? In this instance, I was
> hoping to keep rspec-dev on my topic branch so I didn't pollute my local
> master branch. As it stands, I would need to either merge in my topic branch
> to master or revert to master as-is. Rake would error on the latter option,
> and the first option is undesirable (to me at least) in the hope of keeping
> it easy to merge upstream changes in.
>
> Is the check for master needed? Is it maybe only needed in certain
> circumstances?
>

I *think* I had that in there because I accidentally pushed a topic branch
that I didn't want to push once. Maybe if we add a warning with a yes/no
prompt when you go to push and one of the repos is off master. WDY?


>
> Matt
>
> --
>  Matt Patterson | Design & Code
>  <matt at reprocessed org> | http://www.reprocessed.org/
>
>
>
> _______________________________________________
> 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/20100105/991b3fb5/attachment.html>

From matt-lists at reprocessed.org  Tue Jan  5 13:36:05 2010
From: matt-lists at reprocessed.org (Matt Patterson)
Date: Tue, 5 Jan 2010 18:36:05 +0000
Subject: [rspec-devel] ticket #921: "Fix for git.rb to make Rakefile
	work"
In-Reply-To: <57c63afe1001050822l5f90fb56m4cd02a7c1fcae2a6@mail.gmail.com>
References: <5E6DD9EA-0DB1-4D62-8C87-DFE85F8C617A@reprocessed.org>
	<57c63afe1001050822l5f90fb56m4cd02a7c1fcae2a6@mail.gmail.com>
Message-ID: <DD4293E4-E521-433F-B21C-BB7E43705DE0@reprocessed.org>


On 5 Jan 2010, at 16:22, David Chelimsky wrote:

> On Tue, Jan 5, 2010 at 7:50 AM, Matt Patterson <matt-lists at reprocessed.org> wrote:
>> I've just had a look at this because I got bitten by Rake raising an error before running any tasks in rspec-dev when I nuked my repositories and re-forked because I was so out of date.
>> 
>> https://rspec.lighthouseapp.com/projects/5645-rspec/tickets/921-fix-for-gitrb-to-make-rakefile-work
>> 
>> That's all fine, but I now notice that all_repos_clean? checks you're on the master branch
>> 
>> Is the check for master needed? Is it maybe only needed in certain circumstances?
> 
> I *think* I had that in there because I accidentally pushed a topic branch that I didn't want to push once. Maybe if we add a warning with a yes/no prompt when you go to push and one of the repos is off master. WDY?

How about set an environment var (or use the newish rake args?) to ignore the branch?

    rake git:update IGNORE_BRANCH=1

It sounds like my use case for losing it is less common and less risky than yours for keeping it.

I'll add a fix to my topic branch and update the lighthouse ticket if you're up for it...

Matt

-- 
  Matt Patterson | Design & Code
  <matt at reprocessed org> | http://www.reprocessed.org/




From matt-lists at reprocessed.org  Tue Jan  5 15:54:17 2010
From: matt-lists at reprocessed.org (Matt Patterson)
Date: Tue, 5 Jan 2010 20:54:17 +0000
Subject: [rspec-devel] ticket #921: "Fix for git.rb to make Rakefile
	work"
In-Reply-To: <DD4293E4-E521-433F-B21C-BB7E43705DE0@reprocessed.org>
References: <5E6DD9EA-0DB1-4D62-8C87-DFE85F8C617A@reprocessed.org>
	<57c63afe1001050822l5f90fb56m4cd02a7c1fcae2a6@mail.gmail.com>
	<DD4293E4-E521-433F-B21C-BB7E43705DE0@reprocessed.org>
Message-ID: <3E9BBC5E-D3AC-448A-B673-9697363906AF@reprocessed.org>

On 5 Jan 2010, at 18:36, Matt Patterson wrote:

> It sounds like my use case for losing it is less common and less risky than yours for keeping it.

More risky, even...

Matt


-- 
  Matt Patterson | Design & Code
  <matt at reprocessed org> | http://www.reprocessed.org/




From matt-lists at reprocessed.org  Wed Jan  6 14:33:17 2010
From: matt-lists at reprocessed.org (Matt Patterson)
Date: Wed, 6 Jan 2010 19:33:17 +0000
Subject: [rspec-devel] Specs for problems involving interop with other
	mocking frameworks
Message-ID: <91FDE0A6-3D66-46A7-A9A6-72C7D30ADAC9@reprocessed.org>

Hi all,

I'm trying to write a failing spec for a problem which only occurs when mocking under Mocha (and potentially the other non-rspec frameworks) in rspec-rails. 

I'm not sure what the best way to deal with this is. Ideally, I'd just re-run the existing RenderObserver-related specs in spec/rails/example/view_example_group_spec.rb and the whole spec/rails/matchers/render_template_spec.rb under Mocha, but I'm not sure what the best way to do that is. I mean, I could just `load` the files in and monkey with the config before running them probably through a cuke feature, but that seems kind of icky.

Suggestions gratefully received.

Matt


-- 
  Matt Patterson | Design & Code
  <matt at reprocessed org> | http://www.reprocessed.org/




From dchelimsky at gmail.com  Wed Jan  6 18:13:52 2010
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 6 Jan 2010 17:13:52 -0600
Subject: [rspec-devel] Specs for problems involving interop with other
	mocking frameworks
In-Reply-To: <91FDE0A6-3D66-46A7-A9A6-72C7D30ADAC9@reprocessed.org>
References: <91FDE0A6-3D66-46A7-A9A6-72C7D30ADAC9@reprocessed.org>
Message-ID: <57c63afe1001061513j48ca1674u2887ec045e886abb@mail.gmail.com>

On Wed, Jan 6, 2010 at 1:33 PM, Matt Patterson
<matt-lists at reprocessed.org>wrote:

> Hi all,
>
> I'm trying to write a failing spec for a problem which only occurs when
> mocking under Mocha (and potentially the other non-rspec frameworks) in
> rspec-rails.
>

I saw your lighthouse ticket about this, and I'm a bit confused about what
you're trying to achieve. Mocha does not have a should_receive method, so if
you're using mocha, you shouldn't expect should_receive to work. Ideally
you'd get a NoMethodError on should_receive, but if there's anything that's
loading spec/mocks, should_receive will be defined.

Can you help me understand the use case?


> I'm not sure what the best way to deal with this is. Ideally, I'd just
> re-run the existing RenderObserver-related specs in
> spec/rails/example/view_example_group_spec.rb and the whole
> spec/rails/matchers/render_template_spec.rb under Mocha, but I'm not sure
> what the best way to do that is. I mean, I could just `load` the files in
> and monkey with the config before running them probably through a cuke
> feature, but that seems kind of icky.
>
> Suggestions gratefully received.
>
> Matt
>
>
> --
>  Matt Patterson | Design & Code
>  <matt at reprocessed org> | http://www.reprocessed.org/
>
>
>
> _______________________________________________
> 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/20100106/09eab90a/attachment.html>

From matt-lists at reprocessed.org  Wed Jan  6 19:32:03 2010
From: matt-lists at reprocessed.org (Matt Patterson)
Date: Thu, 7 Jan 2010 00:32:03 +0000
Subject: [rspec-devel] Specs for problems involving interop with other
	mocking frameworks
In-Reply-To: <57c63afe1001061513j48ca1674u2887ec045e886abb@mail.gmail.com>
References: <91FDE0A6-3D66-46A7-A9A6-72C7D30ADAC9@reprocessed.org>
	<57c63afe1001061513j48ca1674u2887ec045e886abb@mail.gmail.com>
Message-ID: <483081EB-6D20-4F2A-9277-948245E3867C@reprocessed.org>


On 6 Jan 2010, at 23:13, David Chelimsky wrote:

> On Wed, Jan 6, 2010 at 1:33 PM, Matt Patterson <matt-lists at reprocessed.org> wrote:
>> Hi all,
>> 
>> I'm trying to write a failing spec for a problem which only occurs when mocking under Mocha (and potentially the other non-rspec frameworks) in rspec-rails.
> 
> I saw your lighthouse ticket about this, and I'm a bit confused about what you're trying to achieve. Mocha does not have a should_receive method, so if you're using mocha, you shouldn't expect should_receive to work. Ideally you'd get a NoMethodError on should_receive, but if there's anything that's loading spec/mocks, should_receive will be defined.
> 
> Can you help me understand the use case?

It's specifically to do with RenderObserver in rspec-rails. RenderObserver explicitly defines its own should_receive method, irrespective of the mocking framework you're using to allow you to use controller.should render_template and template.should_receive(:render).with(:partial => 'x'). 

So, my issue was that something which, AFAIK, is supposed to just work whatever mocking framework you're using, is breaking (silently) when you're not using RSpec's own mocks.

My question here was what the best way to run particular rspec-rails specs under several mocking frameworks is. There are already specs which cover the RenderObserver behaviours, they just need running under all the mocking frameworks RSpec supports.

Matt

>> I'm not sure what the best way to deal with this is. Ideally, I'd just re-run the existing RenderObserver-related specs in spec/rails/example/view_example_group_spec.rb and the whole spec/rails/matchers/render_template_spec.rb under Mocha, but I'm not sure what the best way to do that is. I mean, I could just `load` the files in and monkey with the config before running them probably through a cuke feature, but that seems kind of icky.
>> 
>> Suggestions gratefully received.

-- 
  Matt Patterson | Design & Code
  <matt at reprocessed org> | http://www.reprocessed.org/




From dchelimsky at gmail.com  Mon Jan 11 22:48:46 2010
From: dchelimsky at gmail.com (David Chelimsky)
Date: Mon, 11 Jan 2010 21:48:46 -0600
Subject: [rspec-devel] [ANN] rspec 1.3.0 Released
Message-ID: <57c63afe1001111948p218f59c2k4acd86948f548f51@mail.gmail.com>

rspec version 1.3.0 has been released!

* <http://rspec.info>
* <http://rubyforge.org/projects/rspec>
* <http://github.com/dchelimsky/rspec/wikis>
* <rspec-users at rubyforge.org>
* <rspec-devel at rubyforge.org>

Behaviour Driven Development for Ruby.

Changes:

### Version 1.3.0 / 2010-01-11

* enhancements
  * capture ExpectationNotMet error by default in matcher DSL
    * supports wrapping other expectations
  * added match_unless_raises to matcher DSL
    * supports easy wrapping of t/u assertions in matchers
    * thanks to Chad Fowler and Glenn Vanderburg for the name
  * add chain to matcher DSL (Joe Ferris - #935)
    * see rdoc for Spec::Matchers
  * and_yield provides configurable eval_context
    * Eric Meyer & David Chelimsky
  * CTRL-C actually stops execution! (Bryan Helmkamp - #911)
  * make drb port configurable (Chris Flipse - #875)
  * changed raise_error to raise_exception (#933)
    * kept raise_error aliased, so this is completely
      backwards compatible

* bug fixes
  * don't define top-level context() method when running in IRB (#899)
  * remove Ruby warning for uninitialized ivar (Bryan Helmkamp - #892)
  * fully qualify reference to Default (Alex Sharp - #895)
  * use runtime version of Test::Unit::VERSION in incompatibility message
    (Ryan Bigg - #916)
  * quote paths in RSpec's own specs so people running in paths with
    spaces in them can achieve green too (Ryan Bigg - #917)
  * ensure drb specs run when EADDRNOTAVAIL (Michael Klett - #881)
  * throw_symbol matcher correctly bubbles errors up (#918)
  * make Rakefile work without Cucumber installed (#919 - devrandom)
  * escape . in regexp (#925)
  * align be_true and be_false with Ruby's conditional semantics (#931)
  * print duplicate nested descriptions (when appropriate) (#936)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-devel/attachments/20100111/e1299c9b/attachment.html>

From dchelimsky at gmail.com  Mon Jan 11 22:48:52 2010
From: dchelimsky at gmail.com (David Chelimsky)
Date: Mon, 11 Jan 2010 21:48:52 -0600
Subject: [rspec-devel] [ANN] rspec-rails 1.3.0 Released
Message-ID: <57c63afe1001111948i7c64f25dx27e8d162eb0d9fba@mail.gmail.com>

rspec-rails version 1.3.0 has been released!

* <http://rspec.info>
* <http://rubyforge.org/projects/rspec>
* <http://github.com/dchelimsky/rspec-rails>
* <http://wiki.github.com/dchelimsky/rspec/rails>
* <rspec-devel at rubyforge.org>

Behaviour Driven Development for Ruby on Rails.

Changes:

### Version 1.3.0 / 2010-01-11

* enhancements
  * use stub() instead of stub!() in generators
  * generate gem config in test.rb with 'script/generate rspec'
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-devel/attachments/20100111/4c58c2b9/attachment.html>

From dchelimsky at gmail.com  Mon Jan 11 23:16:54 2010
From: dchelimsky at gmail.com (David Chelimsky)
Date: Mon, 11 Jan 2010 22:16:54 -0600
Subject: [rspec-devel] Chad Humphries
Message-ID: <57c63afe1001112016v4dc456f1sf393c84484b654be@mail.gmail.com>

Welcome Chad Humphries to the Rspec Development Team!

http://blog.davidchelimsky.net/2010/01/12/welcome-chad-humphries/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-devel/attachments/20100111/6764b4c9/attachment.html>

From joahking at gmail.com  Tue Jan 12 04:25:19 2010
From: joahking at gmail.com (Joaquin Rivera Padron)
Date: Tue, 12 Jan 2010 10:25:19 +0100
Subject: [rspec-devel] Chad Humphries
In-Reply-To: <57c63afe1001112016v4dc456f1sf393c84484b654be@mail.gmail.com>
References: <57c63afe1001112016v4dc456f1sf393c84484b654be@mail.gmail.com>
Message-ID: <8277b7f41001120125p69986b33g812b3b90e51ab56d@mail.gmail.com>

congrats spicycode :-)

keep on the good work,
joaquin

2010/1/12 David Chelimsky <dchelimsky at gmail.com>

> Welcome Chad Humphries to the Rspec Development Team!
>
> http://blog.davidchelimsky.net/2010/01/12/welcome-chad-humphries/
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>



-- 
www.least-significant-bit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-devel/attachments/20100112/66851050/attachment-0001.html>

From luislavena at gmail.com  Fri Jan 15 19:22:18 2010
From: luislavena at gmail.com (Luis Lavena)
Date: Fri, 15 Jan 2010 21:22:18 -0300
Subject: [rspec-devel] RSpec, autospec, console redirection,
	colors and Windows
Message-ID: <71166b3b1001151622u546e64dfla31577235e2147f6@mail.gmail.com>

Hello Guys,

I've been working on update win32console gem, which is the one that
provides ANSI coloring for Windows to work with Ruby 1.9.1

Released 2 weeks ago 1.3.0.beta1

And received the following bug report.

http://github.com/luislavena/win32console/issues#issue/3

I can confirm that I can reproduce the issue indicated there consistently.

Every time that color has been enabled in the spec options for the
child process, it terminates itself suddenly terminating autospec too.

I've tried to recreate this scenario with as a minimal scenario:

http://gist.github.com/278537

All this using Ruby 1.9.1, of course.

Using either the options file or the --colour option, ends with no
color from the redirected process.

To complicate things a bit more, seems that the process itself do not
terminate, or the usage of $stderr do not affect the outcome.

So, I can reproduce the issue reported here using autospec, but I
can't using what I think autospec should be doing.

I would like to be able to enable the child process color to mimic
autospec behavior and see if is win32console fault or not.

Any hint or suggestion?

Thank you for your time,
-- 
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exup?ry