Nabble - rspec-devel

Re: should_yield (is it needed?)

2009-11-29T12:11:16Z

On Tue, Nov 10, 2009 at 5:00 PM, David Chelimsky <dchelimsky@...> wrote:

[1,2,3].should yield_on(:each) ???

This does follow rspec syntax more closely... Let's run through a few use cases I can imagine.

current_user.stub!(:admin?).and_return(true)

helper.should yield_on(:admin_only)

# helper.admin_only &should_yield

[1,2,3].should yield_on(:each).each_of(1,2,3)

# [1,2,3].each &should_yield_each(1,2,3)

h = { :a => 1, :b => 2 }

h.should yield_on(:each).each_of(*h.to_a)

h.each &should_yield_each(*h.to_a)

helper.should yield_on(:link_to_function, "link text").with(an_instance_of(JavaScriptHelper::JavaScriptBuilder))

# helper.link_to_function "link text", &should_yield_with(an_instance_of(JavaScriptHelper::JavaScriptBuilder))

I think both are pretty clear until the last example when this part in my format: "link text", &should_yield(...) starts to confuse what's going on exactly. It very clearly breaks from rspec syntax in that example.

helper.link_to_functio("link text", &assert_yielded_block)

That actually makes a bit more sense since the intention is clear. I'm passing a block that asserts that it will be yielded. However, this isn't rspec at all written like that.

The yield_on format seems to specify "When I call this method on the receiver, I expect it to yield." This is very similar to user.should be_an_admin in that the actual method call is not being called on the receiver but passed into the matcher.

Is this something we'd like to add to rspec? If so, I'll work out a patch.

Martin

_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

Re: should_yield (is it needed?)

2009-11-10T17:00:22Z

On Fri, Nov 6, 2009 at 10:43 PM, Martin Emde <martin.emde@...> wrote:

I have the code working for this but I wanted an opinion on making a patch.

I sometimes have the need to expect that a method will yield a block it's given. Usually this means something like this:

   yielded = false
   subject.method { yielded = true }
   yielded.should == true

which is a bit tedious and ugly. My solution might be just as ugly, but I wanted to get feedback because it saves that tedious code.

   subject.method(&should_yield)

I wrote a few methods, that when called, return an object with #to_proc that expects that the proc is called (or not called). I have the following forms available fairly simply:

   subject.method(&should_not_yield)
   subject.method(&should_yield_with(object))

   # Expects 3 yields, one with each argument
   [1,2,3].each(&should_yield_each(1,2,3))

I think this is a little cleaner and the code is very simple. I wanted to get an opinion on whether this is worth making into a patch.

Martin Emde
Tw: @martinemde

Generally this looks really nice, and I can see the use, but it's so different from everything else that I need to think about it a bit more. Have you played around w/ any other syntax options that would be more aligned w/ the "actual.should matcher" format? Something like:

[1,2,3].should yield_on(:each) ???

_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

Re: should_yield (is it needed?)

2009-11-09T21:34:55Z

I happen to think that's brilliant.

Peter

On Fri, Nov 6, 2009 at 10:43 PM, Martin Emde <martin.emde@...> wrote:

> I have the code working for this but I wanted an opinion on making a patch.
> I sometimes have the need to expect that a method will yield a block it's
> given. Usually this means something like this:
>    yielded = false
>    subject.method { yielded = true }
>    yielded.should == true
> which is a bit tedious and ugly. My solution might be just as ugly, but I
> wanted to get feedback because it saves that tedious code.
>    subject.method(&should_yield)
> I wrote a few methods, that when called, return an object with #to_proc that
> expects that the proc is called (or not called). I have the following forms
> available fairly simply:
>    subject.method(&should_not_yield)
>    subject.method(&should_yield_with(object))
>    # Expects 3 yields, one with each argument
>    [1,2,3].each(&should_yield_each(1,2,3))
>
> I think this is a little cleaner and the code is very simple. I wanted to
> get an opinion on whether this is worth making into a patch.
> Martin Emde
> Tw: @martinemde
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel@...
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

Re: describe "RSpec's documentation" do

2009-11-08T08:49:39Z

On Sat, Nov 7, 2009 at 9:31 PM, David Chelimsky <dchelimsky@...> wrote:

On Fri, Nov 6, 2009 at 5:27 PM, Ryan Briones <ryan.briones@...> wrote:

This sounds pretty cool. Are there any ideas or examples of how features would get turned into end user documentation? My first thought is something RDoc like would go in the free-form user story area... I'd certainly like to help as time permitted. I'd definitely like to be more informed of rspec internals.

Yes, we should definitely beef up the narratives in each feature. Then we need to generate the output as HTML and, the tricky part, generate some wrapper HTML to make a site out of the different pages.

As for internals, my goal for the Cucumber features is to provide an executable set of documentation for end users to understand how to use RSpec. Not so much to expose internals, which I think is better addressed in the RSpec code examples themselves. Make sense?

Yes. Being more familiar with the internals was more for my own edification. ;)

On Fri, Nov 6, 2009 at 7:49 AM, David Chelimsky <dchelimsky@...> wrote:

Hi all,

describe "RSpec's documentation" do
it "should be helpful"
it "should be maintainable"
end

I've been wanting to improve RSpec's documentation situation for a long time, but my writing energies have been consumed by rspec itself and The RSpec Book for a longer time, and will continue to do so for the foreseeable future. So I'm going to need some help.

The problem to solve is that we have (at least) four sources of documentation, each of which moves at its own pace and has evolved in its meaning/place:

1. The RSpec code examples that ship with RSpec
2. The Cucumber features that ship with RSpec
3. The github wiki: http://wiki.github.com/dchelimsky/rspec
4. http://rspec.info

The model that Aslak and the Cucumber community has used has worked very well because it's a community effort, but there is still some duplication between what's on the wiki [1] and the Cucumber features/scenarios that ship with Cucumber [2].

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?
* RSpec code examples become a solid source of additional detailed documentation for those who want to either extend RSpec or debug problems.
* http://rspec.info becomes a one pager like http://cukes.info
* The github wiki becomes a community driven resource center with links to tutorials, blogs, matcher libraries, etc, etc

I welcome suggestions, but I really need volunteers volunteers! I'm not going to be able to spend much personal time on this, so if there are any among you who are willing to coordinate with me and drive the effort, I'd love to hear from you.

Cheers,
David

[1] http://wiki.github.com/aslakhellesoy/cucumber
[2] http://github.com/aslakhellesoy/cucumber/tree/master/features/

_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

--
Ryan Carmelo Briones

_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

--
Ryan Carmelo Briones

_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

Re: describe "RSpec's documentation" do

2009-11-07T18:31:06Z

On Fri, Nov 6, 2009 at 5:27 PM, Ryan Briones <ryan.briones@...> wrote:

This sounds pretty cool. Are there any ideas or examples of how features would get turned into end user documentation? My first thought is something RDoc like would go in the free-form user story area... I'd certainly like to help as time permitted. I'd definitely like to be more informed of rspec internals.

Yes, we should definitely beef up the narratives in each feature. Then we need to generate the output as HTML and, the tricky part, generate some wrapper HTML to make a site out of the different pages.

As for internals, my goal for the Cucumber features is to provide an executable set of documentation for end users to understand how to use RSpec. Not so much to expose internals, which I think is better addressed in the RSpec code examples themselves. Make sense?

On Fri, Nov 6, 2009 at 7:49 AM, David Chelimsky <dchelimsky@...> wrote:

Hi all,

describe "RSpec's documentation" do
it "should be helpful"
it "should be maintainable"
end

I've been wanting to improve RSpec's documentation situation for a long time, but my writing energies have been consumed by rspec itself and The RSpec Book for a longer time, and will continue to do so for the foreseeable future. So I'm going to need some help.

The problem to solve is that we have (at least) four sources of documentation, each of which moves at its own pace and has evolved in its meaning/place:

1. The RSpec code examples that ship with RSpec
2. The Cucumber features that ship with RSpec
3. The github wiki: http://wiki.github.com/dchelimsky/rspec
4. http://rspec.info

The model that Aslak and the Cucumber community has used has worked very well because it's a community effort, but there is still some duplication between what's on the wiki [1] and the Cucumber features/scenarios that ship with Cucumber [2].

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?
* RSpec code examples become a solid source of additional detailed documentation for those who want to either extend RSpec or debug problems.
* http://rspec.info becomes a one pager like http://cukes.info
* The github wiki becomes a community driven resource center with links to tutorials, blogs, matcher libraries, etc, etc

I welcome suggestions, but I really need volunteers volunteers! I'm not going to be able to spend much personal time on this, so if there are any among you who are willing to coordinate with me and drive the effort, I'd love to hear from you.

Cheers,
David

[1] http://wiki.github.com/aslakhellesoy/cucumber
[2] http://github.com/aslakhellesoy/cucumber/tree/master/features/

_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

--
Ryan Carmelo Briones

_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

should_yield (is it needed?)

2009-11-06T22:43:42Z

I have the code working for this but I wanted an opinion on making a patch.

I sometimes have the need to expect that a method will yield a block it's given. Usually this means something like this:

yielded = false

subject.method { yielded = true }

yielded.should == true

which is a bit tedious and ugly. My solution might be just as ugly, but I wanted to get feedback because it saves that tedious code.

subject.method(&should_yield)

I wrote a few methods, that when called, return an object with #to_proc that expects that the proc is called (or not called). I have the following forms available fairly simply:

subject.method(&should_not_yield)

subject.method(&should_yield_with(object))

# Expects 3 yields, one with each argument

[1,2,3].each(&should_yield_each(1,2,3))

I think this is a little cleaner and the code is very simple. I wanted to get an opinion on whether this is worth making into a patch.

Martin Emde
Tw: @martinemde

_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

Re: describe "RSpec's documentation" do

2009-11-06T14:27:40Z

This sounds pretty cool. Are there any ideas or examples of how features would get turned into end user documentation? My first thought is something RDoc like would go in the free-form user story area... I'd certainly like to help as time permitted. I'd definitely like to be more informed of rspec internals.

On Fri, Nov 6, 2009 at 7:49 AM, David Chelimsky <dchelimsky@...> wrote:

Hi all,

describe "RSpec's documentation" do
it "should be helpful"
it "should be maintainable"
end

I've been wanting to improve RSpec's documentation situation for a long time, but my writing energies have been consumed by rspec itself and The RSpec Book for a longer time, and will continue to do so for the foreseeable future. So I'm going to need some help.

The problem to solve is that we have (at least) four sources of documentation, each of which moves at its own pace and has evolved in its meaning/place:

1. The RSpec code examples that ship with RSpec
2. The Cucumber features that ship with RSpec
3. The github wiki: http://wiki.github.com/dchelimsky/rspec
4. http://rspec.info

The model that Aslak and the Cucumber community has used has worked very well because it's a community effort, but there is still some duplication between what's on the wiki [1] and the Cucumber features/scenarios that ship with Cucumber [2].

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?
* RSpec code examples become a solid source of additional detailed documentation for those who want to either extend RSpec or debug problems.
* http://rspec.info becomes a one pager like http://cukes.info
* The github wiki becomes a community driven resource center with links to tutorials, blogs, matcher libraries, etc, etc

I welcome suggestions, but I really need volunteers volunteers! I'm not going to be able to spend much personal time on this, so if there are any among you who are willing to coordinate with me and drive the effort, I'd love to hear from you.

Cheers,
David

[1] http://wiki.github.com/aslakhellesoy/cucumber
[2] http://github.com/aslakhellesoy/cucumber/tree/master/features/

_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

--
Ryan Carmelo Briones

_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

describe "RSpec's documentation" do

2009-11-06T04:49:10Z

Hi all,

describe "RSpec's documentation" do
it "should be helpful"
it "should be maintainable"
end

I've been wanting to improve RSpec's documentation situation for a
long time, but my writing energies have been consumed by rspec itself
and The RSpec Book for a longer time, and will continue to do so for
the foreseeable future. So I'm going to need some help.

The problem to solve is that we have (at least) four sources of
documentation, each of which moves at its own pace and has evolved in
its meaning/place:

1. The RSpec code examples that ship with RSpec
2. The Cucumber features that ship with RSpec
3. The github wiki: http://wiki.github.com/dchelimsky/rspec
4. http://rspec.info

The model that Aslak and the Cucumber community has used has worked
very well because it's a community effort, but there is still some
duplication between what's on the wiki [1] and the Cucumber features/
scenarios that ship with Cucumber [2].

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?
* RSpec code examples become a solid source of additional detailed
documentation for those who want to either extend RSpec or debug
problems.
* http://rspec.info becomes a one pager like http://cukes.info
* The github wiki becomes a community driven resource center with
links to tutorials, blogs, matcher libraries, etc, etc

I welcome suggestions, but I really need volunteers volunteers! I'm
not going to be able to spend much personal time on this, so if there
are any among you who are willing to coordinate with me and drive the
effort, I'd love to hear from you.

Cheers,
David

[1] http://wiki.github.com/aslakhellesoy/cucumber
[2] http://github.com/aslakhellesoy/cucumber/tree/master/features/

_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

[ANN] rspec-rails 1.2.9 Released

2009-10-05T21:08:41Z

rspec-rails version 1.2.9 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@...>

Behaviour Driven Development for Ruby on Rails.

Changes:

### Version 1.2.9 / 2009-10-05

* enhancements
* added route_to and be_routable matchers (Randy Harmon). Closes #843.
* Provide better failure message for render_template when redirected (Josh
Nichols). Closes #885.
* generated specs require 'spec_helper'

* bug fixes
* pass the correct args to super in controller#render depending on the rails
version (Lucas Carlson). Closes #865.
* use Rack::Utils.parse_query to convert query strings to hashes. Closes #872.
* errors correctly bubble up when a controller spec in isolation mode
requests a non-existent action/template
* no error if either action or template exist
* error if neither exist
* Closes #888.

* removals
* spec_server has been removed in favor of spork.
* You can still use the --drb flag, but you've got to install the spork
gem.
* Windows users who cannot use the spork gem can install the spec_server
from http://github.com/dchelimsky/spec_server
_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

[ANN] rspec 1.2.9 Released

2009-10-05T21:08:26Z

rspec version 1.2.9 has been released!

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

Behaviour Driven Development for Ruby.

Changes:

### Version 1.2.9 / 2009-10-05

* enhancements
* manage backtrace-ignore patterns with Spec::Runner.configure (Martin
Emde). Closes #870.
* friendly mock argument expectation failure message (Tim Harper). Closes
#868.
* added double() as alias for stub() and mock()
* failure messages for doubles, mocks and stubs use the right name
* add let() method to assign memoized attributes (suggestion from Stuart
Halloway). Closes #857.
* add its method so you can say:
describe Array do
its(:length) { should == 0 }
(Stephen Touset). Closes #833
* spec command automatically uses spec/spec.opts if it is present
(suggestion from Yehuda Katz)
* rspec now adds PROJECT_ROOT/lib and PROJECT_ROOT/spec to the load path
* determines PROJECT_ROOT by recursing up until it finds a directory
that has a ./spec directory (thanks to Scott Taylor)
* supports require 'spec_helper'
* supports running specs from the PROJECT_ROOT or any directory
below it
* closes #733
* better handling of determining test names in test/unit/interop mode
* Joe Ferris
* closes #854

* bug fixes

* Fixed problem with colorized output when writing to a file
* Corey Ehmke
* closes #777

* not really a bug fix or enhancement
* temporarily moved heckle feature to features-pending (waiting to see what
happens with
http://rubyforge.org/tracker/index.php?func=detail&aid=26786&group_id=1513&atid=5921)
_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

[ANN] rspec and rspec-rails 1.2.9.rc1 Released

2009-09-14T17:45:22Z

rspec and rspec-rails version 1.2.9.rc1 have been released!
===========================================================

We're using the new rubygems prerelease feature to do proper release
candidates. This feature was introduced to rubygems a couple of versions back,
but I'd recommend updating to rubygems-1.3.5 before installing the rspec
prerelease gems.

For those unfamiliar with this new rubygems feature, you have to add the
--prerelease flat in order to see and install these gems:

$ gem search --remote --prerelease rspec

*** REMOTE GEMS ***

rspec (1.2.9.rc1)
rspec-rails (1.2.9.rc1)

$ [sudo] gem install --prerelease rspec
$ [sudo] gem install --prerelease rspec-rails

This way only those who choose to install the prerelease gems will get them,
while those who exclude the --prerelease flag will get the previous final
release (rspec-1.2.8, rspec-rails-1.2.7.1).

Once you install the prerelease gems, Rubygems will treat 1.2.9.rc1 as a
higher version than 1.2.8, but a lower version than 1.2.9. That way when we do
the final release you'll be able to just install 1.2.9 and it will take its
rightful place ahead of 1.2.9.rc1 without you having to uninstall rc1.

I invite you to install these prerelease gems and report any issues you run
into to http://rspec.lighthouseapp.com/rspec. Advanced thanks to those who
help the rest by breaking these in.

Cheers,
David

===========================================================

Behaviour Driven Development for Ruby and Ruby on Rails

### rspec-1.2.9-rc1

* enhancements
* manage backtrace-ignore patterns with Spec::Runner.configure
(Martin Emde). Closes #870.
* friendly mock argument expectation failure message (Tim Harper).
Closes #868.
* added double() as alias for stub() and mock()
* failure messages for doubles, mocks and stubs use the right name
* add let() method to assign memoized attributes (suggestion from
Stuart Halloway). Closes #857.
* add its method so you can say:
describe Array do
its(:length) { should == 0 }
(Stephen Touset). Closes #833
* spec command automatically uses spec/spec.opts if it is present
(suggestion from Yehuda Katz)
* rspec now adds PROJECT_ROOT/lib and PROJECT_ROOT/spec to the load path
* determines PROJECT_ROOT by recursing up until it finds a directory
that has a ./spec directory (thanks to Scott Taylor)
* supports require 'spec_helper'
* supports running specs from the PROJECT_ROOT or any directory
below it
* closes #733

* not really a bug fix or enhancement
* temporarily moved heckle feature to features-pending (waiting to see what
happens with
http://rubyforge.org/tracker/index.php?func=detail&aid=26786&group_id=1513&atid=5921)

### rspec-rails-1.2.9-rc1

* enhancements
* added route_to and be_routable matchers (Randy Harmon). Closes #843.
* Provide better failure message for render_template when redirected
(Josh Nichols). Closes #885.
* generated specs require 'spec_helper'

* bug fixes
* pass the correct args to super in controller#render depending on
the rails version (Lucas Carlson). Closes #865.
* use Rack::Utils.parse_query to convert query strings to hashes. Closes #872.
* errors correctly bubble up when a controller spec in isolation
mode requests a non-existent action/template
* no error if either action or template exist
* error if neither exist
* Closes #888.

* removals
* spec_server has been removed in favor of spork.
* You can still use the --drb flag, but you've got to install the spork gem.
* Windows users who cannot use the spork gem can install the
spec_server from
* http://github.com/dchelimsky/spec_server

* <http://rspec.info>
* <http://rubyforge.org/projects/rspec>
* <http://github.com/dchelimsky/rspec>
* <http://github.com/dchelimsky/rspec-rails>
* <http://wiki.github.com/dchelimsky/rspec>
* <rspec-users@...>
* <rspec-devel@...>
_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

feedback on name for a new method

2009-08-21T05:25:03Z

Hey all,

Please check out
https://rspec.lighthouseapp.com/projects/5645/tickets/857 and, if
you're interested, comment on your preferred name - options are
"assign" and "define"

TIA,
David
_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

help with a method name for a new feature request

2009-07-19T09:03:44Z

Hey all,

I need some help with a method name. Please read and comment in
https://rspec.lighthouseapp.com/projects/5645-rspec/tickets/857.

Thanks,
David
_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

[ANN] rspec 1.2.8 Released

2009-07-16T19:25:40Z

rspec version 1.2.8 has been released!

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

Behaviour Driven Development for Ruby.

Changes:

### Version 1.2.8 / 2008-07-16

* enhancements
* better messages for should[_not] be_nil (Chad Humphries and Rob Sanheim)
* should and should_not accept optional custom message
(suggestion from Rob Sanheim)
* result.should be_nil, "expected result to be nil"
* added 'spec/stubs/cucumber' to plug RSpec's stubbing framework into
Cucumber scenarios.
* added unstub method to remove a stub mid-example (Scott Taylor). Closes
#853.
* add more readable diff when expected and actual are hashes (Ryan Bigg).
Closes #848.

* bug fixes
* fixed --line option for ruby 1.9.1
* fix stub_chain conflict between two chains starting with the same message
(Mike Rohland). Closes #846.
_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

Re: [ANN] rspec-rails 1.2.7 Released

2009-06-22T22:16:51Z

I just pushed 1.2.7.1 to fix a bug in "script/generate rspec". Please
use this instead of the 1.2.7 gem.

Cheers,
David

On Mon, Jun 22, 2009 at 9:21 PM, David Chelimsky<dchelimsky@...> wrote:

> rspec-rails-1.2.7 has been released!
>
> Behaviour Driven Development for Ruby on Rails.
>
> Changes:
>
> ### Version 1.2.7 / 2009-06-22
>
> * enhancements
> * alias :stub!, :stub so rspec-rails extensions of rspec stubs can use the
> same syntax as rspec (core)
> * integration specs (Ben Mabey and David Chelimsky)
> * added support for references and belongs_to generated model specs (José
> Valim). Closes #792.
> * add discovery for autotest-rails to keep compatible with ZenTest-4.0.0
> (Ryan Davis). Closes #838.
> * controller specs in isolation mode don't care whether the file exists
> anymore!
>
> * bug fixes
> * allow rspec-rails to work without ActiveRecord. Closes #810.
> * fix bug with have() matcher failure message (Dave Giunta). Closes #818.
> * fix bug where render_template('new') would pass if 'newer' was rendered
> (or anything that started with 'new')
>
> * deprecations
> * spec_server is now deprecated - use spork instead (gem install spork).
> Closes #827.
>
> * <http://rspec.info>
> * <http://rubyforge.org/projects/rspec>
> * <http://github.com/dchelimsky/rspec-rails>
> * <http://wiki.github.com/dchelimsky/rspec/rails>
> * <rspec-devel@...>
>

_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

[ANN] rspec-rails 1.2.7 Released

2009-06-22T19:21:40Z

rspec-rails-1.2.7 has been released!

Behaviour Driven Development for Ruby on Rails.

Changes:

### Version 1.2.7 / 2009-06-22

* enhancements
* alias :stub!, :stub so rspec-rails extensions of rspec stubs can use the
same syntax as rspec (core)
* integration specs (Ben Mabey and David Chelimsky)
* added support for references and belongs_to generated model specs (José
Valim). Closes #792.
* add discovery for autotest-rails to keep compatible with ZenTest-4.0.0
(Ryan Davis). Closes #838.
* controller specs in isolation mode don't care whether the file exists
anymore!

* bug fixes
* allow rspec-rails to work without ActiveRecord. Closes #810.
* fix bug with have() matcher failure message (Dave Giunta). Closes #818.
* fix bug where render_template('new') would pass if 'newer' was rendered
(or anything that started with 'new')

* deprecations
* spec_server is now deprecated - use spork instead (gem install spork).
Closes #827.

* <http://rspec.info>
* <http://rubyforge.org/projects/rspec>
* <http://github.com/dchelimsky/rspec-rails>
* <http://wiki.github.com/dchelimsky/rspec/rails>
* <rspec-devel@...>
_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

[ANN] rspec 1.2.7 Released

2009-06-22T19:21:32Z

rspec-1.2.7 has been released!

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

Behaviour Driven Development for Ruby.

Changes:

### Version 1.2.7 / 2009-06-22

* enhancments
* added support for fakes using obj.stub(:method) { # implementation }
* allow subject { self } (Jarmo Pertman). Closes #816.
* friendly error message when a matcher returns nil on a failure message
* add ruby_cmd option to SpecTask (Rick DeNatale). Closes #823.
* also added missing specs for SpecTask - thanks Rick!
* add support for generating matchers with fluent interfaces with the
Matcher DSL

* bug fixes
* NegativeOperatorMatcher now returns false (Wesley Beary). Closes #812.
* derive MockExpectationError from Exception rather than StandardError
(Kerry Buckley). Closes #830.
* fix bug where multi-line failure messages weren't getting picked up by
autotest (Jarmo Pertman). Closes #832.
* --line_number now works for it { should xxx } format (assist from Fred
Lee)
* warn instead of raise when there is no description supplied for an
example. Closes #840.

* <http://rspec.info>
* <http://rubyforge.org/projects/rspec>
* <http://github.com/dchelimsky/rspec/wikis>
* <rspec-users@...>
* <rspec-devel@...>
_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

[Cucumber] ANN: New Google Group for Cucumber

2009-05-18T11:12:03Z

David Chelimsky and I have decided that it's now best to create a
separate mailing list for Cucumber.
The RSpec mailing lists remain the same, but we're hoping that you
will all move Cucumber related discussions to this new list.
I have already sent an invitation to the 98 people who have provided
patches to Cucumber (taken from the Git log). Others can subscribe
manually.

See you at http://groups.google.com/group/cukes

Cheers,
Aslak
_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

Re: Building Cucumber for Java on Windows

2009-05-18T06:23:46Z

On Mon, May 18, 2009 at 2:26 PM, Luis Lavena <luislavena@...> wrote:

2009/5/18 Trond Marius Øvstetun <trond@...>:

> Hi.
>
> I am having problems running the rake tasks for Cucumber for Java on
> Windows.
> When I run "jruby -S rake gem" in Cygwin I get the following stack:
>

The first thing is that you're running JRuby inside Cygwin. all batch
file calls will be intercepted by cygwin and not by the OS, thus
failing...

> [...]

> mvn clean package
> /usr/bin/sh: call: command not found
> rake aborted!

"call" is an internal command of Windows interpreter, that should have
work on a plain console.

>
> When I run in the regular cmd-shell:
> C:\Users\ovstetun\Mesan\fagArbeid\cucumber_java\cucumber-java>jruby -S rake
> gem --trace
> (in C:/Users/ovstetun/Mesan/fagArbeid/cucumber_java/cucumber-java)

> [...]

>
>
> Are these known problems? Anything to fix?
> So far I have changed the rake-tasks the following:
> task :jar do
> # sh 'mvn clean package'
> mv "target/cucumber-java-#{Cucumber::Java::VERSION::STRING}.jar", 'lib'
> end
>
> Then things work as long as I remember to run mvn package between each
> execution of rake gem..
> Any tips to making this work?
>

Can you upgrade to rake 0.8.7? There are known problems of
Kernel::system() on Windows that got fixed several versions after
0.8.4. Also, latest 0.8.7 fixed issues when calling shell commands
form JRuby.

Tried to update everything, including rake. Now I get the following trace:

C:\Users\ovstetun\Mesan\fagArbeid\cucumber_java\cucumber-java>jruby -S rake gem --trace
(in C:/Users/ovstetun/Mesan/fagArbeid/cucumber_java/cucumber-java)
** README.txt is missing or in the wrong format for auto-intuiting.
run `sow blah` and look at its text files
** History.txt is missing or in the wrong format for auto-intuiting.
run `sow blah` and look at its text files
** Invoke gem (first_time)
** Invoke pkg/cucumber-java-0.0.2.gem (first_time)
** Invoke pkg (first_time, not_needed)
** Invoke README.txt (first_time, not_needed)
rake aborted!
Don't know how to build task 'lib/cucumber-java-0.0.2.jar'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:1728:in `[]'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:605:in `invoke_prerequisites'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:604:in `each'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:604:in `invoke_prerequisites'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:596:in `invoke_with_call_chain'
C:/Java/jruby-1.2.0/bin/../lib/ruby/1.8/monitor.rb:191:in `mon_synchronize'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:590:in `invoke_with_call_chain'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:607:in `invoke_prerequisites'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:604:in `each'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:604:in `invoke_prerequisites'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:596:in `invoke_with_call_chain'
C:/Java/jruby-1.2.0/bin/../lib/ruby/1.8/monitor.rb:191:in `mon_synchronize'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:590:in `invoke_with_call_chain'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:583:in `invoke'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2051:in `invoke_task'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2029:in `top_level'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2029:in `each'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2029:in `top_level'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2068:in `standard_exception_handling'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2023:in `top_level'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2001:in `run'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2068:in `standard_exception_handling'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:1998:in `run'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.7/bin/rake:31
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.7/bin/rake:19:in `load'
C:\Java\jruby-1.2.0\bin\..\bin\rake:19

Any ideas?

gem update rake

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

--
TronD

_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

Re: Building Cucumber for Java on Windows

2009-05-18T05:26:48Z

2009/5/18 Trond Marius Øvstetun <trond@...>:
> Hi.
>
> I am having problems running the rake tasks for Cucumber for Java on
> Windows.
> When I run "jruby -S rake gem" in Cygwin I get the following stack:
>

The first thing is that you're running JRuby inside Cygwin. all batch
file calls will be intercepted by cygwin and not by the OS, thus
failing...

> [...]
> mvn clean package
> /usr/bin/sh: call: command not found
> rake aborted!

"call" is an internal command of Windows interpreter, that should have
work on a plain console.

>
> When I run in the regular cmd-shell:
> C:\Users\ovstetun\Mesan\fagArbeid\cucumber_java\cucumber-java>jruby -S rake
> gem --trace
> (in C:/Users/ovstetun/Mesan/fagArbeid/cucumber_java/cucumber-java)
> [...]
>
>
> Are these known problems? Anything to fix?
> So far I have changed the rake-tasks the following:
> task :jar do
> # sh 'mvn clean package'
> mv "target/cucumber-java-#{Cucumber::Java::VERSION::STRING}.jar", 'lib'
> end
>
> Then things work as long as I remember to run mvn package between each
> execution of rake gem..
> Any tips to making this work?
>

Can you upgrade to rake 0.8.7? There are known problems of
Kernel::system() on Windows that got fixed several versions after
0.8.4. Also, latest 0.8.7 fixed issues when calling shell commands
form JRuby.

gem update rake

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

Building Cucumber for Java on Windows

2009-05-18T00:50:59Z

Hi.

I am having problems running the rake tasks for Cucumber for Java on Windows.
When I run "jruby -S rake gem" in Cygwin I get the following stack:

ovstetun@trall cucumber-java>jruby -S rake gem --trace
(in C:/Users/ovstetun/Mesan/fagArbeid/cucumber_java/cucumber-java)
JRuby limited openssl loaded. gem install jruby-openssl for full support.
http://wiki.jruby.org/wiki/JRuby_Builtin_OpenSSL
** README.txt is missing or in the wrong format for auto-intuiting.
   run `sow blah` and look at its text files
** History.txt is missing or in the wrong format for auto-intuiting.
   run `sow blah` and look at its text files
** Invoke gem (first_time)
** Invoke pkg/cucumber-java-0.0.2.gem (first_time, not_needed)
** Invoke pkg (first_time, not_needed)
** Invoke README.txt (first_time, not_needed)
** Invoke lib/cucumber-java-0.0.2.jar (first_time, not_needed)
** Invoke lib/cucumber/java.rb (first_time, not_needed)
** Invoke lib/cucumber/spring.rb (first_time, not_needed)
** Invoke lib/cucumber/pico_container.rb (first_time, not_needed)
** Invoke lib/cucumber/java/version.rb (first_time, not_needed)
** Invoke jar (first_time)
** Execute jar
mvn clean package
/usr/bin/sh: call: command not found
rake aborted!
Command failed with status (127): [mvn clean package...]
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:969:in `sh'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:982:in `call'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:982:in `sh'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:1074:in `sh'
C:/Users/ovstetun/Mesan/fagArbeid/cucumber_java/cucumber-java/rakefile:60
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:617:in `call'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:617:in `execute'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:612:in `each'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:612:in `execute'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:578:in `invoke_with_call_chain'
c:/Java/jruby-1.2.0/lib/ruby/1.8/monitor.rb:191:in `mon_synchronize'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:571:in `invoke_with_call_chain'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:588:in `invoke_prerequisites'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:585:in `each'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:585:in `invoke_prerequisites'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:577:in `invoke_with_call_chain'
c:/Java/jruby-1.2.0/lib/ruby/1.8/monitor.rb:191:in `mon_synchronize'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:571:in `invoke_with_call_chain'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:564:in `invoke'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:2027:in `invoke_task'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:2005:in `top_level'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:2005:in `each'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:2005:in `top_level'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:2044:in `standard_exception_handling'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:1999:in `top_level'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:1977:in `run'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:2044:in `standard_exception_handling'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:1974:in `run'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/bin/rake:31
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/bin/rake:19:in `load'
c:\Java\jruby-1.2.0\bin\rake:19

When I run in the regular cmd-shell:
C:\Users\ovstetun\Mesan\fagArbeid\cucumber_java\cucumber-java>jruby -S rake gem --trace
(in C:/Users/ovstetun/Mesan/fagArbeid/cucumber_java/cucumber-java)
JRuby limited openssl loaded. gem install jruby-openssl for full support.
http://wiki.jruby.org/wiki/JRuby_Builtin_OpenSSL
** README.txt is missing or in the wrong format for auto-intuiting.
   run `sow blah` and look at its text files
** History.txt is missing or in the wrong format for auto-intuiting.
   run `sow blah` and look at its text files
** Invoke gem (first_time)
** Invoke pkg/cucumber-java-0.0.2.gem (first_time, not_needed)
** Invoke pkg (first_time, not_needed)
** Invoke README.txt (first_time, not_needed)
** Invoke lib/cucumber-java-0.0.2.jar (first_time, not_needed)
** Invoke lib/cucumber/java.rb (first_time, not_needed)
** Invoke lib/cucumber/spring.rb (first_time, not_needed)
** Invoke lib/cucumber/pico_container.rb (first_time, not_needed)
** Invoke lib/cucumber/java/version.rb (first_time, not_needed)
** Invoke jar (first_time)
** Execute jar
mvn clean package
rake aborted!
private method `split' called for nil:NilClass
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake/repaired_system.rb:109:in `find_runnable
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake/repaired_system.rb:73:in `repair_command
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake/repaired_system.rb:125:in `system'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake/win32.rb:23:in `rake_system'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:988:in `rake_system'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:981:in `sh'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:1074:in `sh'
C:/Users/ovstetun/Mesan/fagArbeid/cucumber_java/cucumber-java/rakefile:60
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:617:in `call'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:617:in `execute'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:612:in `each'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:612:in `execute'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:578:in `invoke_with_call_chain'
C:/Java/jruby-1.2.0/bin/../lib/ruby/1.8/monitor.rb:191:in `mon_synchronize'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:571:in `invoke_with_call_chain'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:588:in `invoke_prerequisites'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:585:in `each'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:585:in `invoke_prerequisites'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:577:in `invoke_with_call_chain'
C:/Java/jruby-1.2.0/bin/../lib/ruby/1.8/monitor.rb:191:in `mon_synchronize'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:571:in `invoke_with_call_chain'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:564:in `invoke'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:2027:in `invoke_task'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:2005:in `top_level'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:2005:in `each'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:2005:in `top_level'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:2044:in `standard_exception_handling'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:1999:in `top_level'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:1977:in `run'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:2044:in `standard_exception_handling'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:1974:in `run'
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/bin/rake:31
C:/Java/jruby-1.2.0/lib/ruby/gems/1.8/gems/rake-0.8.4/bin/rake:19:in `load'
C:\Java\jruby-1.2.0\bin\..\bin\rake:19

Are these known problems? Anything to fix?
So far I have changed the rake-tasks the following:
task :jar do
# sh 'mvn clean package'
mv "target/cucumber-java-#{Cucumber::Java::VERSION::STRING}.jar", 'lib'
end

Then things work as long as I remember to run mvn package between each execution of rake gem..
Any tips to making this work?

--
TronD

_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

Re: [Cucumber] --must-not-pass option

2009-05-14T05:17:37Z

On Wed, May 13, 2009 at 5:34 AM, Perryn Fowler <pezlists@...> wrote:

>> Personally I would love to name the switch --work-in-progress or --wip (-w)
>> The help text would explain the failure logic.
>>
>> I think this name would be more educational too.
>>
>> WDYT?
>
> Yeah, I like that. I'll change it and remove the rake tasks on my fork
> then send you another pull request
>

I have done a diff on your master branch - from the commit prior to
your first commit up to your last one.

github pull perryn
git checkout perryn/master
git diff bc51edfa5..849634ca

The diff is here:

http://gist.github.com/111636

This is a fairly substantial diff (1300+ lines), and I can't just
merge that in. It changes a lot more than it needs to in order to
implement this fairly simple feature (--must-not-pass/--wip).

Things I believe should be in a separate branch/diff:

* Rake task (ref Ben's comment)
* Mucking with the backtrace formatting
* Random whitespace

Could you please create a new branch (from my current master) and
implement *only* the --wip option? Then I'll pull it in.

Cheers,
Aslak

>
>
> --
> -----------------------
> Perryn Fowler
> ThoughtWorks
> _______________________________________________
> rspec-devel mailing list
> rspec-devel@...
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

Re: [Cucumber] --must-not-pass option

2009-05-12T20:34:40Z

> Personally I would love to name the switch --work-in-progress or --wip (-w)
> The help text would explain the failure logic.
>
> I think this name would be more educational too.
>
> WDYT?

Yeah, I like that. I'll change it and remove the rake tasks on my fork
then send you another pull request

--
-----------------------
Perryn Fowler
ThoughtWorks
_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

Re: [Cucumber] --must-not-pass option

2009-05-12T00:21:54Z

On Tue, May 12, 2009 at 8:17 AM, Perryn Fowler <pezlists@...> wrote:

> I don't think that the rake tasks should be included in Cucumber, but the
> --must-not-pass option is nice.

Yeah, I mainly included them and their tests and features as a kind of
documentation in the code base for why --must-not-pass exists.

I found it difficult to explain why on earth I would want that option
without talking about my need for in_progress and regression builds,
so I added them as an explicit use case.

Personally I would love to name the switch --work-in-progress or --wip (-w)
The help text would explain the failure logic.

I think this name would be more educational too.

WDYT?

Aslak

perhaps it would have been better to stick with the blog

Pez

_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

Re: [Cucumber] --must-not-pass option

2009-05-11T23:17:00Z

> I don't think that the rake tasks should be included in Cucumber, but the
> --must-not-pass option is nice.

Yeah, I mainly included them and their tests and features as a kind of
documentation in the code base for why --must-not-pass exists.

I found it difficult to explain why on earth I would want that option
without talking about my need for in_progress and regression builds,
so I added them as an explicit use case.

perhaps it would have been better to stick with the blog

Pez
_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

Re: [Cucumber] --must-not-pass option

2009-05-11T19:57:45Z

Ben Mabey wrote:

> aslak hellesoy wrote:
>>
>> Hi there,
>>
>> I recently created a fork of Cucumber for use on my current project,
>> and Aslak asked me to start a discussion here to see if it is
>> something we would want to merge back into a Cucumber release.
>>
>> I have attempted to explain the reasoning behind my changes here :
>> http://www.jroller.com/perryn/entry/bdd_on_a_multi_disciplined
>>
>> The rake tasks mentioned are really just window dressing for a new
>> --must-not-pass option that fails the suite if any individual
>> Scenario
>> passes.
>>
>> Thoughts?
>>
>>
>> Thanks for a well-written blog post that explains the rationale
>> behind it. I especially like the tie-in to WIP, since I'm a huge
>> Kanban fan.
>> Let me mull it over for a couple of days.
>>
>> Would anyone else find this useful?
>>
>> Aslak
>
> I like it. I've been using a similar workflow with the tags @proposed
> and @in_progress, and profiles 'proposed', 'in_progress', and 'done'.
> I never thought of having the in-progress profile fail if they pass,
> but it makes sense. So, I really like the idea of having it in Cucumber.
>
> I don't think that the rake tasks should be included in Cucumber, but
> the --must-not-pass option is nice. However, should we change it to
> "--must-fail"?

Actually, now that I think about it maybe "--must-not-pass" is better
since it could also be pending and be fine.

>
> -Ben
>
>>
>>
>>
>> Pez
>>
>> --
>> -----------------------
>> Perryn Fowler
>> ThoughtWorks
>> _______________________________________________
>> rspec-devel mailing list
>> rspec-devel@... <mailto:rspec-devel@...>
>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> rspec-devel mailing list
>> rspec-devel@...
>> http://rubyforge.org/mailman/listinfo/rspec-devel
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel@...
> http://rubyforge.org/mailman/listinfo/rspec-devel

_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

Re: [Cucumber] --must-not-pass option

2009-05-11T18:49:26Z

aslak hellesoy wrote:

>
> Hi there,
>
> I recently created a fork of Cucumber for use on my current project,
> and Aslak asked me to start a discussion here to see if it is
> something we would want to merge back into a Cucumber release.
>
> I have attempted to explain the reasoning behind my changes here :
> http://www.jroller.com/perryn/entry/bdd_on_a_multi_disciplined
>
> The rake tasks mentioned are really just window dressing for a new
> --must-not-pass option that fails the suite if any individual Scenario
> passes.
>
> Thoughts?
>
>
> Thanks for a well-written blog post that explains the rationale behind
> it. I especially like the tie-in to WIP, since I'm a huge Kanban fan.
> Let me mull it over for a couple of days.
>
> Would anyone else find this useful?
>
> Aslak

I like it. I've been using a similar workflow with the tags @proposed
and @in_progress, and profiles 'proposed', 'in_progress', and 'done'.
I never thought of having the in-progress profile fail if they pass, but
it makes sense. So, I really like the idea of having it in Cucumber.

I don't think that the rake tasks should be included in Cucumber, but
the --must-not-pass option is nice. However, should we change it to
"--must-fail"?

-Ben

>
>
>
> Pez
>
> --
> -----------------------
> Perryn Fowler
> ThoughtWorks
> _______________________________________________
> rspec-devel mailing list
> rspec-devel@... <mailto:rspec-devel@...>
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel@...
> http://rubyforge.org/mailman/listinfo/rspec-devel

_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

Re: this library needs a better name

2009-05-11T18:12:19Z

On Mon, May 11, 2009 at 8:07 PM, Zach Dennis <zach.dennis@...> wrote:

> On Sun, May 3, 2009 at 1:57 PM, David Chelimsky <dchelimsky@...> wrote:
>> On Sun, May 3, 2009 at 12:54 PM, David Chelimsky <dchelimsky@...> wrote:
>>> On Sun, May 3, 2009 at 12:40 PM, aslak hellesoy
>>> <aslak.hellesoy@...> wrote:
>>>>
>>>>
>>>> On Sun, May 3, 2009 at 7:32 PM, Mark Wilden <mark@...> wrote:
>>>>>
>>>>> On Sat, May 2, 2009 at 11:12 PM, David Chelimsky <dchelimsky@...>
>>>>> wrote:
>>>>>>
>>>>>> The basic idea is that you use the stubble method to define a family
>>>>>> of stubs on a model class and the instance it returns for new(),
>>>>>> find(), create(), and create!(). There's a bit more than that, but
>>>>>> it's an infant right now, and there are certainly going to be holes in
>>>>>> it, but the biggest hole at the moment is its name :)
>>>>>
>>>>> Since the library is for stubbing models, I actually like the name
>>>>> stubble.
>>>>
>>>> Why not include it in rspec-rails?
>>>
>>> I may eventually, but I want to prove it out for a bit before adding
>>> it to the mile long list of shit that I have to maintain in rspec
>>> rails to maintain compatibility.
>>
>> Also, a bigger problem than the lib name is the method. This doesn't
>> speak to me:
>>
>> stubble(MyModel)
>>
>> It needs to say "take control of this model class and provide
>> instances that are savable (or not) for find, new, create, and
>> create!" - all of that in one word.
>
> I like "stub_model" for this as well even though its taken. Based on
> the name you pick, you will potentially need to change the name of
> "stub_model", otherwise the API is going to become diluted and less
> meaningful. Yes, I know it's one method, but stub_model doesn't do
> what you think it does and this new behaviour does what I'd think
> stub_model would do.
>
>>
>> Was chatting w/ imajes (James Cox) last night and I mentioned the word
>> stage, at which point we came up variations of this:
>>
>> stage(Model).as :savable do |model|
>> # access to the one and only model instance
>> end
>
> stage doesn't do it for me. It seems like grasping for straws because
> the good names have been taken. In your original post you already gave
> two important words... it needs to "stub" stuff on the "model". What
> else could be more clear?
>
>>
>> Thoughts?
>
> You could keep existing "stub-model" behaviour and add on the new,
> until the old is deprecated?
>
> stub_model(MyModel).as :savable

Hey Zach,

Thanks for your thoughts on this but at this point I've already
announced the library name as stubble and the method it uses is
stubbing:

stubbing(Thing) do |thing|
get :index
assigns[:things].should == [thing]
end

More at http://github.com/dchelimsky/stubble/tree/master

Cheers,
David

>
>
>>
>>
>>>
>>>>
>>>> Aslak
>>>>
>>>>>
>>>>> ///ark
>>>>>
>>>>> _______________________________________________
>>>>> rspec-devel mailing list
>>>>> rspec-devel@...
>>>>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>>>
>>>>
>>>> _______________________________________________
>>>> rspec-devel mailing list
>>>> rspec-devel@...
>>>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>>>
>>>
>> _______________________________________________
>> rspec-devel mailing list
>> rspec-devel@...
>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>
>
>
>
> --
> Zach Dennis
> http://www.continuousthinking.com (personal)
> http://www.mutuallyhuman.com (hire me)
> @zachdennis (twitter)
> _______________________________________________
> rspec-devel mailing list
> rspec-devel@...
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

Re: this library needs a better name

2009-05-11T18:07:04Z

On Sun, May 3, 2009 at 1:57 PM, David Chelimsky <dchelimsky@...> wrote:

> On Sun, May 3, 2009 at 12:54 PM, David Chelimsky <dchelimsky@...> wrote:
>> On Sun, May 3, 2009 at 12:40 PM, aslak hellesoy
>> <aslak.hellesoy@...> wrote:
>>>
>>>
>>> On Sun, May 3, 2009 at 7:32 PM, Mark Wilden <mark@...> wrote:
>>>>
>>>> On Sat, May 2, 2009 at 11:12 PM, David Chelimsky <dchelimsky@...>
>>>> wrote:
>>>>>
>>>>> The basic idea is that you use the stubble method to define a family
>>>>> of stubs on a model class and the instance it returns for new(),
>>>>> find(), create(), and create!(). There's a bit more than that, but
>>>>> it's an infant right now, and there are certainly going to be holes in
>>>>> it, but the biggest hole at the moment is its name :)
>>>>
>>>> Since the library is for stubbing models, I actually like the name
>>>> stubble.
>>>
>>> Why not include it in rspec-rails?
>>
>> I may eventually, but I want to prove it out for a bit before adding
>> it to the mile long list of shit that I have to maintain in rspec
>> rails to maintain compatibility.
>
> Also, a bigger problem than the lib name is the method. This doesn't
> speak to me:
>
> stubble(MyModel)
>
> It needs to say "take control of this model class and provide
> instances that are savable (or not) for find, new, create, and
> create!" - all of that in one word.

I like "stub_model" for this as well even though its taken. Based on
the name you pick, you will potentially need to change the name of
"stub_model", otherwise the API is going to become diluted and less
meaningful. Yes, I know it's one method, but stub_model doesn't do
what you think it does and this new behaviour does what I'd think
stub_model would do.

>
> Was chatting w/ imajes (James Cox) last night and I mentioned the word
> stage, at which point we came up variations of this:
>
> stage(Model).as :savable do |model|
> # access to the one and only model instance
> end

stage doesn't do it for me. It seems like grasping for straws because
the good names have been taken. In your original post you already gave
two important words... it needs to "stub" stuff on the "model". What
else could be more clear?

>
> Thoughts?

You could keep existing "stub-model" behaviour and add on the new,
until the old is deprecated?

stub_model(MyModel).as :savable

>
>
>>
>>>
>>> Aslak
>>>
>>>>
>>>> ///ark
>>>>
>>>> _______________________________________________
>>>> rspec-devel mailing list
>>>> rspec-devel@...
>>>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>>
>>>
>>> _______________________________________________
>>> rspec-devel mailing list
>>> rspec-devel@...
>>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>>
>>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel@...
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

--
Zach Dennis
http://www.continuousthinking.com (personal)
http://www.mutuallyhuman.com (hire me)
@zachdennis (twitter)
_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

Re: [Cucumber] --must-not-pass option

2009-05-11T10:26:39Z

Hi there,

I recently created a fork of Cucumber for use on my current project,
and Aslak asked me to start a discussion here to see if it is
something we would want to merge back into a Cucumber release.

I have attempted to explain the reasoning behind my changes here :
http://www.jroller.com/perryn/entry/bdd_on_a_multi_disciplined

The rake tasks mentioned are really just window dressing for a new
--must-not-pass option that fails the suite if any individual Scenario
passes.

Thoughts?

Thanks for a well-written blog post that explains the rationale behind it. I especially like the tie-in to WIP, since I'm a huge Kanban fan.
Let me mull it over for a couple of days.

Would anyone else find this useful?

Aslak

Pez

--
-----------------------
Perryn Fowler
ThoughtWorks
_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

[Cucumber] --must-not-pass option

2009-05-11T05:34:53Z

Hi there,

I recently created a fork of Cucumber for use on my current project,
and Aslak asked me to start a discussion here to see if it is
something we would want to merge back into a Cucumber release.

I have attempted to explain the reasoning behind my changes here :
http://www.jroller.com/perryn/entry/bdd_on_a_multi_disciplined

The rake tasks mentioned are really just window dressing for a new
--must-not-pass option that fails the suite if any individual Scenario
passes.

Thoughts?

Pez

--
-----------------------
Perryn Fowler
ThoughtWorks
_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

Re: this library needs a better name

2009-05-03T22:38:05Z

On Sun, May 3, 2009 at 9:52 PM, Dan North <tastapod@...> wrote:

How about...

2009/5/4 David Chelimsky <dchelimsky@...>

On Sun, May 3, 2009 at 12:54 PM, David Chelimsky <dchelimsky@...> wrote:
> On Sun, May 3, 2009 at 12:40 PM, aslak hellesoy
> <aslak.hellesoy@...> wrote:
>>
>>
>> On Sun, May 3, 2009 at 7:32 PM, Mark Wilden <mark@...> wrote:
>>>
>>> On Sat, May 2, 2009 at 11:12 PM, David Chelimsky <dchelimsky@...>
>>> wrote:
>>>>
>>>> The basic idea is that you use the stubble method to define a family
>>>> of stubs on a model class and the instance it returns for new(),
>>>> find(), create(), and create!(). There's a bit more than that, but
>>>> it's an infant right now, and there are certainly going to be holes in
>>>> it, but the biggest hole at the moment is its name :)
>>>
>>> Since the library is for stubbing models, I actually like the name
>>> stubble.
>>
>> Why not include it in rspec-rails?
>
> I may eventually, but I want to prove it out for a bit before adding
> it to the mile long list of shit that I have to maintain in rspec
> rails to maintain compatibility.

Also, a bigger problem than the lib name is the method. This doesn't
speak to me:

stubble(MyModel)

pwn(MyModel)

pr0n(MyModel)

? :-)

It needs to say "take control of this model class and provide
instances that are savable (or not) for find, new, create, and
create!" - all of that in one word.

IN YR MODEL PWNING YR SAVEZ LOL!

KTHXBYE

Was chatting w/ imajes (James Cox) last night and I mentioned the word
stage, at which point we came up variations of this:

stage(Model).as :savable do |model|
# access to the one and only model instance
end

Thoughts?

>
>>
>> Aslak
>>
>>>
>>> ///ark
>>>
>>> _______________________________________________
>>> rspec-devel mailing list
>>> rspec-devel@...
>>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>
>>
>> _______________________________________________
>> rspec-devel mailing list
>> rspec-devel@...
>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>
>
_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

Re: this library needs a better name

2009-05-03T22:21:03Z

pimp(MyModel)

On Mon, May 4, 2009 at 2:52 PM, Dan North <tastapod@...> wrote:

How about...

2009/5/4 David Chelimsky <dchelimsky@...>

On Sun, May 3, 2009 at 12:54 PM, David Chelimsky <dchelimsky@...> wrote:
> On Sun, May 3, 2009 at 12:40 PM, aslak hellesoy
> <aslak.hellesoy@...> wrote:
>>
>>
>> On Sun, May 3, 2009 at 7:32 PM, Mark Wilden <mark@...> wrote:
>>>
>>> On Sat, May 2, 2009 at 11:12 PM, David Chelimsky <dchelimsky@...>
>>> wrote:
>>>>
>>>> The basic idea is that you use the stubble method to define a family
>>>> of stubs on a model class and the instance it returns for new(),
>>>> find(), create(), and create!(). There's a bit more than that, but
>>>> it's an infant right now, and there are certainly going to be holes in
>>>> it, but the biggest hole at the moment is its name :)
>>>
>>> Since the library is for stubbing models, I actually like the name
>>> stubble.
>>
>> Why not include it in rspec-rails?
>
> I may eventually, but I want to prove it out for a bit before adding
> it to the mile long list of shit that I have to maintain in rspec
> rails to maintain compatibility.

Also, a bigger problem than the lib name is the method. This doesn't
speak to me:

stubble(MyModel)

pwn(MyModel)

It needs to say "take control of this model class and provide
instances that are savable (or not) for find, new, create, and
create!" - all of that in one word.

IN YR MODEL PWNING YR SAVEZ LOL!

KTHXBYE

Was chatting w/ imajes (James Cox) last night and I mentioned the word
stage, at which point we came up variations of this:

stage(Model).as :savable do |model|
# access to the one and only model instance
end

Thoughts?

>
>>
>> Aslak
>>
>>>
>>> ///ark
>>>
>>> _______________________________________________
>>> rspec-devel mailing list
>>> rspec-devel@...
>>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>
>>
>> _______________________________________________
>> rspec-devel mailing list
>> rspec-devel@...
>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>
>
_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

Re: this library needs a better name

2009-05-03T21:52:59Z

How about...

2009/5/4 David Chelimsky <dchelimsky@...>

On Sun, May 3, 2009 at 12:54 PM, David Chelimsky <dchelimsky@...> wrote:
> On Sun, May 3, 2009 at 12:40 PM, aslak hellesoy
> <aslak.hellesoy@...> wrote:
>>
>>
>> On Sun, May 3, 2009 at 7:32 PM, Mark Wilden <mark@...> wrote:
>>>
>>> On Sat, May 2, 2009 at 11:12 PM, David Chelimsky <dchelimsky@...>
>>> wrote:
>>>>
>>>> The basic idea is that you use the stubble method to define a family
>>>> of stubs on a model class and the instance it returns for new(),
>>>> find(), create(), and create!(). There's a bit more than that, but
>>>> it's an infant right now, and there are certainly going to be holes in
>>>> it, but the biggest hole at the moment is its name :)
>>>
>>> Since the library is for stubbing models, I actually like the name
>>> stubble.
>>
>> Why not include it in rspec-rails?
>
> I may eventually, but I want to prove it out for a bit before adding
> it to the mile long list of shit that I have to maintain in rspec
> rails to maintain compatibility.

Also, a bigger problem than the lib name is the method. This doesn't
speak to me:

stubble(MyModel)

pwn(MyModel)

It needs to say "take control of this model class and provide
instances that are savable (or not) for find, new, create, and
create!" - all of that in one word.

IN YR MODEL PWNING YR SAVEZ LOL!

KTHXBYE

Was chatting w/ imajes (James Cox) last night and I mentioned the word
stage, at which point we came up variations of this:

stage(Model).as :savable do |model|
# access to the one and only model instance
end

Thoughts?

>
>>
>> Aslak
>>
>>>
>>> ///ark
>>>
>>> _______________________________________________
>>> rspec-devel mailing list
>>> rspec-devel@...
>>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>
>>
>> _______________________________________________
>> rspec-devel mailing list
>> rspec-devel@...
>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>
>
_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

Re: this library needs a better name

2009-05-03T16:58:25Z

I love the idea.

I think "stubble" is a bit esoteric though, I almost prefer the example with two more lines of code, just for it's readability.

Having said that, I haven't been able to come up with a name myself :P

"stub_model" seems perfect, apart from the fact that it's already taken.

John Doxey

DiUS Computing

On Mon, May 4, 2009 at 6:11 AM, Mark Wilden <mark@...> wrote:

On Sun, May 3, 2009 at 10:57 AM, David Chelimsky <dchelimsky@...> wrote:

Also, a bigger problem than the lib name is the method. This doesn't
speak to me:

stubble(MyModel)

stubblize(MyModel)

The contraction of "stub model" to "stubble" really speaks to me. :)

///ark

_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel