From dchelimsky at gmail.com Sun Oct 1 11:23:50 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 1 Oct 2006 10:23:50 -0500 Subject: [rspec-devel] Partial Mocks In-Reply-To: <1d7ddd110609302007o1d8aca12s36ab74108840eb25@mail.gmail.com> References: <1d7ddd110609302007o1d8aca12s36ab74108840eb25@mail.gmail.com> Message-ID: <57c63afe0610010823s3f27587xe51616e60866048c@mail.gmail.com> On 9/30/06, Brian Takita wrote: > I added Partial Mocking, aka Class Level Mocking. COOL! >For now, I added > should_receive and should_not_receive to Object, but it can be moved to > Class and/or its own module. > > I understand the Partial Mocking is controversial and dangerous if used > incorrectly, but I've been finding myself using them with success. > I'd advocate that Partial Mocking is a "sharp knife" that, if used > correctly, can be a nice tool that simplifies tests/specs. Where I see this as necessary (and useful) is in cases like ActiveRecord subclasses that are designed to be used as their own factories. In static languages, this would be viewed as a big no-no by the TDD community, but the fact that Ruby makes it so easy to intercept calls changes the landscape a bit. What we *could* do, if we all agree that we prefer to encourage partial mocking at the class level but discourage it at the instance level, is make it a module that we include in the Class class. Then, if a developer chooses to add it to instances of a class, he can include it in the class in the spec file. This way it's only automagic on classes, but still accessible on instances. > Of course when used incorrectly, it can "slice through bone". What is your view of correct/incorrect? Maybe we should come up w/ some guidelines for that for the rspec documentation. > Anyways, here is an example. It is committed inside of the stubs branch. > How should we proceed? Let's let it stew in the branch for a few days, but not too long. I'm planning to do the 0.6.4 release tomorrow (sans partial mocking and stubbing) just to get a wealth of improvements out. No reason this can't be in a 0.6.5 release later this week. > require File.dirname(__FILE__) + '/../lib/spec' > > class MockableClass > def self.find id > return :original_return > end > end > > context "A partial mock" do > > specify "should be able to stub objects" do > obj = Object.new > obj.should_receive(:foobar).and_return {:return_value} > obj.foobar.should_equal :return_value > end > > specify "should work at the class level" do > MockableClass.should_receive(:find).and_return {:stub_return} > MockableClass.find(1).should_equal :stub_return > end > > specify "should revert to the original after each spec" do > MockableClass.find(1).should_equal :original_return > end > > end How about MockableClass.should_receive(:find).with("1").and_return {:stub_return} ??? > > Thanks, > Brian As insincere as this phrase usually sounds, I mean it sincerely: no, thank you! This is a very important part of rspec support for rails apps. A lot of ppl are using mocha/stubba w/ test/unit because class level mocking/stubbing is such a great aid to testing controllers and views. This is a real deficiency in rspec, and I think that resolving it will open the rspec door for a lot more rails developers. Of course, we're also going to offer a plugin seam for mocha/stubba, flexmock, or any other framework, so people who prefer them can use them. But none of them have the same syntax as the other rspec expectations, so I like the idea of continuing to support these facilities out of the box in rspec. David From brian.takita at gmail.com Sun Oct 1 14:56:47 2006 From: brian.takita at gmail.com (Brian Takita) Date: Sun, 1 Oct 2006 11:56:47 -0700 Subject: [rspec-devel] Partial Mocks In-Reply-To: <57c63afe0610010823s3f27587xe51616e60866048c@mail.gmail.com> References: <1d7ddd110609302007o1d8aca12s36ab74108840eb25@mail.gmail.com> <57c63afe0610010823s3f27587xe51616e60866048c@mail.gmail.com> Message-ID: <1d7ddd110610011156p13ce6cf7nfad76ae5b6631ff@mail.gmail.com> On 10/1/06, David Chelimsky wrote: > > On 9/30/06, Brian Takita wrote: > > I added Partial Mocking, aka Class Level Mocking. > > COOL! > > >For now, I added > > should_receive and should_not_receive to Object, but it can be moved to > > Class and/or its own module. > > > > I understand the Partial Mocking is controversial and dangerous if used > > incorrectly, but I've been finding myself using them with success. > > I'd advocate that Partial Mocking is a "sharp knife" that, if used > > correctly, can be a nice tool that simplifies tests/specs. > > Where I see this as necessary (and useful) is in cases like > ActiveRecord subclasses that are designed to be used as their own > factories. In static languages, this would be viewed as a big no-no by > the TDD community, but the fact that Ruby makes it so easy to > intercept calls changes the landscape a bit. > What we *could* do, if we all agree that we prefer to encourage > partial mocking at the class level but discourage it at the instance > level, is make it a module that we include in the Class class. Then, > if a developer chooses to add it to instances of a class, he can > include it in the class in the spec file. I moved partial mocking into its own module and removed default support for Object. I added support to Module. It's more that partial mocks are needed for constants and potentially singletons. Constants tend to be modules and classes so I figure that it would be useful in module for the same reasons that it is useful for class. This way it's only automagic on classes, but still accessible on instances. The partial mocking module takes care of that. > Of course when used incorrectly, it can "slice through bone". > > What is your view of correct/incorrect? Maybe we should come up w/ > some guidelines for that for the rspec documentation. I think partial mocking is useful even for instances because it can reduce the scope of unit tests and avoid lots of setup or fixture logic. Often times, the object being tested depends on another object's state. I think that for unit tests, we should not be concerned about how to set up the parent. I've been finding myself following this pattern: foobar_called = false another_obj.stub!(:foobar).with {foobar_called = true; false;} obj.something foobar_called.should_equal true Of course, partial mocking would make this clearer another_obj.extend Mocks::PartialMock another_obj.should_receive(:foobar).and_return(false) obj.something Obviously there are places where partial mocks can quickly confuse things. It is probably not a good idea to partially mock the class you are testing. If you feel the temptation to, then the class probably has too many responsibilities. Partial mocking is also less compelling for functional tests, but the same is true for mocks. What are your thoughts? > Anyways, here is an example. It is committed inside of the stubs branch. > > How should we proceed? > > Let's let it stew in the branch for a few days, but not too long. I'm > planning to do the 0.6.4 release tomorrow (sans partial mocking and > stubbing) just to get a wealth of improvements out. No reason this > can't be in a 0.6.5 release later this week. Sounds good. > require File.dirname(__FILE__) + '/../lib/spec' > > > > class MockableClass > > def self.find id > > return :original_return > > end > > end > > > > context "A partial mock" do > > > > specify "should be able to stub objects" do > > obj = Object.new > > obj.should_receive(:foobar).and_return {:return_value} > > obj.foobar.should_equal :return_value > > end > > > > specify "should work at the class level" do > > MockableClass.should_receive(:find).and_return {:stub_return} > > MockableClass.find(1).should_equal :stub_return > > end > > > > specify "should revert to the original after each spec" do > > MockableClass.find(1).should_equal :original_return > > end > > > > end > > How about MockableClass.should_receive(:find).with("1").and_return > {:stub_return} ??? Yes, that works too. I added it to the example. > > > Thanks, > > Brian > > As insincere as this phrase usually sounds, I mean it sincerely: no, > thank you! This is a very important part of rspec support for rails > apps. A lot of ppl are using mocha/stubba w/ test/unit because class > level mocking/stubbing is such a great aid to testing controllers and > views. This is a real deficiency in rspec, and I think that resolving > it will open the rspec door for a lot more rails developers. Your welcome and the pleasure is mine. :) I'm having fun working on rspec. Of course, we're also going to offer a plugin seam for mocha/stubba, > flexmock, or any other framework, so people who prefer them can use > them. But none of them have the same syntax as the other rspec > expectations, so I like the idea of continuing to support these > facilities out of the box in rspec. I agree. Rspec also has pretty good mock/stub support. It can even be seperated into its own gem. David > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061001/70b6261a/attachment-0001.html From dchelimsky at gmail.com Mon Oct 2 06:58:39 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 2 Oct 2006 05:58:39 -0500 Subject: [rspec-devel] stubs Message-ID: <57c63afe0610020358m12636dt3f0ab0c50c907129@mail.gmail.com> Hey Brian, I'm trying to use the stubbing and partial_mocking. Check this out: If I do this: Story.stub!(:new).with(@story) all is well. But if I do this: Story.stub!(:find).with(@story) I get a bunch of errors like this: singleton method called for a different object I think it's a conflict w/ rails' usage of the Story metaclass. Here's my theory (something akin to a wild ass guess) :new is defined on Story when it is initially loaded, but :find is added by rails at runtime, making a new metaclass. RSpec is telling Story to stub! :find, but :find is not defined on Story, it's defined on a run-time rails variation of Story. Any thoughts on this? David From luke at agileevolved.com Mon Oct 2 07:41:30 2006 From: luke at agileevolved.com (Luke Redpath) Date: Mon, 2 Oct 2006 12:41:30 +0100 Subject: [rspec-devel] stubs In-Reply-To: <57c63afe0610020358m12636dt3f0ab0c50c907129@mail.gmail.com> References: <57c63afe0610020358m12636dt3f0ab0c50c907129@mail.gmail.com> Message-ID: <30F85306-5C6B-43C7-B7FC-0FD7BBD48E48@agileevolved.com> I'm pretty sure that find() is defined in ActiveRecord::Base explicitly. I never had any problems stubbing find() with Stubba. However, I was never able to stub the methods that are definately generated at run-time, such as find_by_* and related finders. Cheers Luke > I think it's a conflict w/ rails' usage of the Story metaclass. Here's > my theory (something akin to a wild ass guess) :new is defined on > Story when it is initially loaded, but :find is added by rails at > runtime, making a new metaclass. RSpec is telling Story to stub! > :find, but :find is not defined on Story, it's defined on a run-time > rails variation of Story. > > Any thoughts on this? > > David > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From dchelimsky at gmail.com Mon Oct 2 09:01:52 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 2 Oct 2006 08:01:52 -0500 Subject: [rspec-devel] stubs In-Reply-To: <30F85306-5C6B-43C7-B7FC-0FD7BBD48E48@agileevolved.com> References: <57c63afe0610020358m12636dt3f0ab0c50c907129@mail.gmail.com> <30F85306-5C6B-43C7-B7FC-0FD7BBD48E48@agileevolved.com> Message-ID: <57c63afe0610020601p2ee691e2o183dfc2e5398e534@mail.gmail.com> On 10/2/06, Luke Redpath wrote: > I'm pretty sure that find() is defined in ActiveRecord::Base > explicitly. True. > I never had any problems stubbing find() with Stubba. > > However, I was never able to stub the methods that are definately > generated at run-time, such as find_by_* and related finders. > > Cheers > Luke > > > I think it's a conflict w/ rails' usage of the Story metaclass. Here's > > my theory (something akin to a wild ass guess) :new is defined on > > Story when it is initially loaded, but :find is added by rails at > > runtime, making a new metaclass. RSpec is telling Story to stub! > > :find, but :find is not defined on Story, it's defined on a run-time > > rails variation of Story. > > > > Any thoughts on this? I found out something else of interest. On AR derivatives, this works: (class << Person; self; end).stub!(:create).with(false) but this doesn't Person.stub!(:create).with(false) Maybe that shed's some light? I'm still searching.... > > > > David > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dchelimsky at gmail.com Mon Oct 2 11:12:39 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 2 Oct 2006 10:12:39 -0500 Subject: [rspec-devel] [ANN] RSpec 0.6.4 released Message-ID: <57c63afe0610020812r301b5744qfaae607a7ae79933@mail.gmail.com> We've released RSpec 0.6.4. Check it out! Check it out! Release info: http://rubyforge.org/frs/shownotes.php?release_id=7178 General info: http://rspec.rubyforge.org/ Questions? Right here! Enjoy, David From dchelimsky at gmail.com Mon Oct 2 12:34:31 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 2 Oct 2006 11:34:31 -0500 Subject: [rspec-devel] [Rspec-users] [ANN] RSpec 0.6.4 released In-Reply-To: References: <57c63afe0610020812r301b5744qfaae607a7ae79933@mail.gmail.com> Message-ID: <57c63afe0610020934n4ad13fb2oef8a742d46a645db@mail.gmail.com> On 10/2/06, Mike Pence wrote: > I think the biggest question is the one that has been posed most > recently on these lists and not answered: > > How do you use RSpec for integration testing (in the Rails sense of > integration testing meaning tests that span controllers)? There's no explicit support for this at this point. Does anyone else have any experience trying to do this? From brian.takita at gmail.com Mon Oct 2 13:28:22 2006 From: brian.takita at gmail.com (Brian Takita) Date: Mon, 2 Oct 2006 10:28:22 -0700 Subject: [rspec-devel] stubs In-Reply-To: <57c63afe0610020601p2ee691e2o183dfc2e5398e534@mail.gmail.com> References: <57c63afe0610020358m12636dt3f0ab0c50c907129@mail.gmail.com> <30F85306-5C6B-43C7-B7FC-0FD7BBD48E48@agileevolved.com> <57c63afe0610020601p2ee691e2o183dfc2e5398e534@mail.gmail.com> Message-ID: <1d7ddd110610021028q73f2269dx58877263e24a8f15@mail.gmail.com> > > I found out something else of interest. On AR derivatives, this works: > > (class << Person; self; end).stub!(:create).with(false) > > but this doesn't > > Person.stub!(:create).with(false) > Interesting. I'll be able to look at this tonight. On 10/2/06, David Chelimsky wrote: > > On 10/2/06, Luke Redpath wrote: > > I'm pretty sure that find() is defined in ActiveRecord::Base > > explicitly. > > True. > > > I never had any problems stubbing find() with Stubba. > > > > However, I was never able to stub the methods that are definately > > generated at run-time, such as find_by_* and related finders. > > > > Cheers > > Luke > > > > > I think it's a conflict w/ rails' usage of the Story metaclass. Here's > > > my theory (something akin to a wild ass guess) :new is defined on > > > Story when it is initially loaded, but :find is added by rails at > > > runtime, making a new metaclass. RSpec is telling Story to stub! > > > :find, but :find is not defined on Story, it's defined on a run-time > > > rails variation of Story. > > > > > > Any thoughts on this? > > I found out something else of interest. On AR derivatives, this works: > > (class << Person; self; end).stub!(:create).with(false) > > but this doesn't > > Person.stub!(:create).with(false) > > Maybe that shed's some light? I'm still searching.... > > > > > > > David > > > _______________________________________________ > > > rspec-devel mailing list > > > rspec-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061002/5a65a38c/attachment.html From brian.takita at gmail.com Mon Oct 2 16:15:37 2006 From: brian.takita at gmail.com (Brian Takita) Date: Mon, 2 Oct 2006 13:15:37 -0700 Subject: [rspec-devel] [Rspec-users] [ANN] RSpec 0.6.4 released In-Reply-To: <57c63afe0610020934n4ad13fb2oef8a742d46a645db@mail.gmail.com> References: <57c63afe0610020812r301b5744qfaae607a7ae79933@mail.gmail.com> <57c63afe0610020934n4ad13fb2oef8a742d46a645db@mail.gmail.com> Message-ID: <1d7ddd110610021315g54364039vdd950dbddbe7c8d7@mail.gmail.com> You can try context "" do inherit ActionController::IntegrationTest end On 10/2/06, David Chelimsky wrote: > > On 10/2/06, Mike Pence wrote: > > I think the biggest question is the one that has been posed most > > recently on these lists and not answered: > > > > How do you use RSpec for integration testing (in the Rails sense of > > integration testing meaning tests that span controllers)? > > There's no explicit support for this at this point. Does anyone else > have any experience trying to do this? > _______________________________________________ > 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/20061002/200566aa/attachment.html From dchelimsky at gmail.com Mon Oct 2 18:33:14 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 2 Oct 2006 17:33:14 -0500 Subject: [rspec-devel] stubs In-Reply-To: <1d7ddd110610021028q73f2269dx58877263e24a8f15@mail.gmail.com> References: <57c63afe0610020358m12636dt3f0ab0c50c907129@mail.gmail.com> <30F85306-5C6B-43C7-B7FC-0FD7BBD48E48@agileevolved.com> <57c63afe0610020601p2ee691e2o183dfc2e5398e534@mail.gmail.com> <1d7ddd110610021028q73f2269dx58877263e24a8f15@mail.gmail.com> Message-ID: <57c63afe0610021533h75d97339y8382b1cc2faf46cc@mail.gmail.com> On 10/2/06, Brian Takita wrote: > > I found out something else of interest. On AR derivatives, this works: > > > > (class << Person; self; end).stub!(:create).with(false > > ) > > > > but this doesn't > > > > Person.stub!(:create).with(false) > > Interesting. I'll be able to look at this tonight. I checked in a file w/ some stuff commented: vendor/rspec_on_rails/spec/controllers/person_controller_spec.rb That should give you an idea of some of the behaviour I'm seeing. Very weird stuff. Hope you enjoy it! David From dchelimsky at gmail.com Mon Oct 2 18:33:30 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 2 Oct 2006 17:33:30 -0500 Subject: [rspec-devel] stubs In-Reply-To: <57c63afe0610021533h75d97339y8382b1cc2faf46cc@mail.gmail.com> References: <57c63afe0610020358m12636dt3f0ab0c50c907129@mail.gmail.com> <30F85306-5C6B-43C7-B7FC-0FD7BBD48E48@agileevolved.com> <57c63afe0610020601p2ee691e2o183dfc2e5398e534@mail.gmail.com> <1d7ddd110610021028q73f2269dx58877263e24a8f15@mail.gmail.com> <57c63afe0610021533h75d97339y8382b1cc2faf46cc@mail.gmail.com> Message-ID: <57c63afe0610021533v564c3f61va69ec7b960cc89f9@mail.gmail.com> On 10/2/06, David Chelimsky wrote: > On 10/2/06, Brian Takita wrote: > > > I found out something else of interest. On AR derivatives, this works: > > > > > > (class << Person; self; end).stub!(:create).with(false > > > ) > > > > > > but this doesn't > > > > > > Person.stub!(:create).with(false) > > > > Interesting. I'll be able to look at this tonight. > > I checked in a file w/ some stuff commented: That's in the stubs branch. > > vendor/rspec_on_rails/spec/controllers/person_controller_spec.rb > > That should give you an idea of some of the behaviour I'm seeing. Very > weird stuff. Hope you enjoy it! > > David > From brian.takita at gmail.com Tue Oct 3 03:36:35 2006 From: brian.takita at gmail.com (Brian Takita) Date: Tue, 3 Oct 2006 00:36:35 -0700 Subject: [rspec-devel] stubs In-Reply-To: <57c63afe0610021533v564c3f61va69ec7b960cc89f9@mail.gmail.com> References: <57c63afe0610020358m12636dt3f0ab0c50c907129@mail.gmail.com> <30F85306-5C6B-43C7-B7FC-0FD7BBD48E48@agileevolved.com> <57c63afe0610020601p2ee691e2o183dfc2e5398e534@mail.gmail.com> <1d7ddd110610021028q73f2269dx58877263e24a8f15@mail.gmail.com> <57c63afe0610021533h75d97339y8382b1cc2faf46cc@mail.gmail.com> <57c63afe0610021533v564c3f61va69ec7b960cc89f9@mail.gmail.com> Message-ID: <1d7ddd110610030036y57a27611j11d871b3521b2f78@mail.gmail.com> I fixed it. I noticed that you where using assigns[:person].should_be person instead of assigns(:person).should_be person Anyways, the context looks like: context "/person/show/3" do fixtures :people controller_name :person specify "should get person with id => 3 from model" do person = mock("person") Person.should_receive(:find).with("3").and_return(person) #Person.stub!(:find).with(person) get 'show', :id => 3 assigns(:person).should_be person end end On 10/2/06, David Chelimsky wrote: > > On 10/2/06, David Chelimsky wrote: > > On 10/2/06, Brian Takita wrote: > > > > I found out something else of interest. On AR derivatives, this > works: > > > > > > > > (class << Person; self; end).stub!(:create).with(false > > > > ) > > > > > > > > but this doesn't > > > > > > > > Person.stub!(:create).with(false) > > > > > > Interesting. I'll be able to look at this tonight. > > > > I checked in a file w/ some stuff commented: > > That's in the stubs branch. > > > > > vendor/rspec_on_rails/spec/controllers/person_controller_spec.rb > > > > That should give you an idea of some of the behaviour I'm seeing. Very > > weird stuff. Hope you enjoy it! > > > > David > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061003/65a0b1bc/attachment-0001.html From mike.pence at gmail.com Mon Oct 2 12:20:37 2006 From: mike.pence at gmail.com (Mike Pence) Date: Mon, 2 Oct 2006 12:20:37 -0400 Subject: [rspec-devel] [Rspec-users] [ANN] RSpec 0.6.4 released In-Reply-To: <57c63afe0610020812r301b5744qfaae607a7ae79933@mail.gmail.com> References: <57c63afe0610020812r301b5744qfaae607a7ae79933@mail.gmail.com> Message-ID: I think the biggest question is the one that has been posed most recently on these lists and not answered: How do you use RSpec for integration testing (in the Rails sense of integration testing meaning tests that span controllers)? Great work. Mike Pence On 10/2/06, David Chelimsky wrote: > We've released RSpec 0.6.4. Check it out! Check it out! > > Release info: > http://rubyforge.org/frs/shownotes.php?release_id=7178 > > General info: > http://rspec.rubyforge.org/ > > Questions? Right here! > > Enjoy, > David > _______________________________________________ > Rspec-users mailing list > Rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From noreply at rubyforge.org Mon Oct 2 17:28:17 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 2 Oct 2006 17:28:17 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-5948 ] rails_spec_runner called rails_spec_server in documentation Message-ID: <20061002212817.AD399524170C@rubyforge.org> Bugs item #5948, was opened at 2006-09-29 03:39 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=5948&group_id=797 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Antti Tarvainen (tarvaina) >Assigned to: Aslak Hellesoy (aslak_hellesoy) Summary: rails_spec_runner called rails_spec_server in documentation Initial Comment: In http://rspec.rubyforge.org/tools/rails.html: [...] Running specs faster with rails_spec Loading the entire Rails environment every time a spec is executed is quite slow. We have therefore made a little tool that allows you to load the rails environment once for all. In a separate shell, run: script/rails_spec_server [...] Shouldn't this be script/rails_spec_runner ---------------------------------------------------------------------- >Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-02 17:28 Message: Fixed in 0.6.4. From the release notes: Renamed rails_spec_runner to rails_spec_server (as referred to in the docs) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=5948&group_id=797 From noreply at rubyforge.org Mon Oct 2 17:29:08 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 2 Oct 2006 17:29:08 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-5947 ] script/rails_spec_runner doesn't work on Windows Message-ID: <20061002212908.8C2E15241719@rubyforge.org> Bugs item #5947, was opened at 2006-09-29 03:37 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=5947&group_id=797 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Antti Tarvainen (tarvaina) >Assigned to: Aslak Hellesoy (aslak_hellesoy) Summary: script/rails_spec_runner doesn't work on Windows Initial Comment: rails_spec_runner doesn't work on Windows. C:\my_project>ruby script/rails_spec_runner Loading Rails environment script/rails_spec_runner:45:in `trap': unsupported signal SIGUSR2 (ArgumentError) ---------------------------------------------------------------------- >Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-02 17:29 Message: Fixed in 0.6.4. From the changelog: Applied [#5728] rails_spec_runner fails on Windows (Patch from Lindsay Evans). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=5947&group_id=797 From jerry.west at ntlworld.com Tue Oct 3 05:23:22 2006 From: jerry.west at ntlworld.com (Jerry West) Date: Tue, 03 Oct 2006 10:23:22 +0100 Subject: [rspec-devel] [Rspec-users] [ANN] RSpec 0.6.4 released In-Reply-To: <57c63afe0610020934n4ad13fb2oef8a742d46a645db@mail.gmail.com> References: <57c63afe0610020812r301b5744qfaae607a7ae79933@mail.gmail.com> <57c63afe0610020934n4ad13fb2oef8a742d46a645db@mail.gmail.com> Message-ID: <45222C0A.1090006@ntlworld.com> I have just integrated IntegrationTest support into REL_0_6_3 (doh! what timing!). As soon as my subscription to rspec-devel comes through I'll post the diffs (to the plugin, nothing else) for discussion - it works for me but may not for others. It doesn't work for REL_0_6_4 out of the box, as #sugarize_for_rspec [spec/lib/api/...] has disappeared, but presumably the plugin authors have to fix that one too. Rgds, Jerry David Chelimsky wrote: > On 10/2/06, Mike Pence wrote: > >> I think the biggest question is the one that has been posed most >> recently on these lists and not answered: >> >> How do you use RSpec for integration testing (in the Rails sense of >> integration testing meaning tests that span controllers)? >> > > There's no explicit support for this at this point. Does anyone else > have any experience trying to do this? > _______________________________________________ > Rspec-users mailing list > Rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From dchelimsky at gmail.com Tue Oct 3 08:26:03 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 3 Oct 2006 07:26:03 -0500 Subject: [rspec-devel] list moderation Message-ID: <57c63afe0610030526w4087c18al7e4e4a7732904991@mail.gmail.com> Hi all - apologies for the bombardment of email from the list this AM. I've never moderated one of these and didn't really keep up w/ the messages. I'll be sure to review them more regularly. Cheers, David From dchelimsky at gmail.com Tue Oct 3 12:05:18 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 3 Oct 2006 11:05:18 -0500 Subject: [rspec-devel] stubs In-Reply-To: <1d7ddd110610030036y57a27611j11d871b3521b2f78@mail.gmail.com> References: <57c63afe0610020358m12636dt3f0ab0c50c907129@mail.gmail.com> <30F85306-5C6B-43C7-B7FC-0FD7BBD48E48@agileevolved.com> <57c63afe0610020601p2ee691e2o183dfc2e5398e534@mail.gmail.com> <1d7ddd110610021028q73f2269dx58877263e24a8f15@mail.gmail.com> <57c63afe0610021533h75d97339y8382b1cc2faf46cc@mail.gmail.com> <57c63afe0610021533v564c3f61va69ec7b960cc89f9@mail.gmail.com> <1d7ddd110610030036y57a27611j11d871b3521b2f78@mail.gmail.com> Message-ID: <57c63afe0610030905i43eb3ae0k2793bf6ff361acdf@mail.gmail.com> On 10/3/06, Brian Takita wrote: > I fixed it. I noticed that you where using > assigns[:person].should_be person > instead of > assigns(:person).should_be person Doh! > > Anyways, the context looks like: > > context "/person/show/3" do > fixtures :people > controller_name :person > > specify "should get person with id => 3 from model" do > person = mock("person") > > > Person.should_receive(:find).with("3").and_return(person) > #Person.stub!(:find).with(person) > get 'show', :id => 3 > > assigns(:person).should_be person > end > end OK - There's still a problem, and it turns out the problem is a bit sinister. Here's the test that exposes the problem: class EmptyClass end class SubclassOfEmptyClass end def test_reset_proxied_methods_should_revert_to_original_when_method_already_exists_in_base_class class << EmptyClass def foobar :original_value end end SubclassOfEmptyClass.stub!(:foobar).with(:return_value) SubclassOfEmptyClass.reset_proxied_methods! assert :original_value, SubclassOfEmptyClass.foobar end I've got that test committed and I'm working on the problem this afternoon. I'll follow up when it's resovled! Later, David From dchelimsky at gmail.com Tue Oct 3 16:12:21 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 3 Oct 2006 15:12:21 -0500 Subject: [rspec-devel] stubs In-Reply-To: <57c63afe0610030905i43eb3ae0k2793bf6ff361acdf@mail.gmail.com> References: <57c63afe0610020358m12636dt3f0ab0c50c907129@mail.gmail.com> <30F85306-5C6B-43C7-B7FC-0FD7BBD48E48@agileevolved.com> <57c63afe0610020601p2ee691e2o183dfc2e5398e534@mail.gmail.com> <1d7ddd110610021028q73f2269dx58877263e24a8f15@mail.gmail.com> <57c63afe0610021533h75d97339y8382b1cc2faf46cc@mail.gmail.com> <57c63afe0610021533v564c3f61va69ec7b960cc89f9@mail.gmail.com> <1d7ddd110610030036y57a27611j11d871b3521b2f78@mail.gmail.com> <57c63afe0610030905i43eb3ae0k2793bf6ff361acdf@mail.gmail.com> Message-ID: <57c63afe0610031312uc87235dncf9cd5e8ee9cc5f0@mail.gmail.com> On 10/3/06, David Chelimsky wrote: > On 10/3/06, Brian Takita wrote: > > I fixed it. I noticed that you where using > > assigns[:person].should_be person > > instead of > > assigns(:person).should_be person > > Doh! > > > > > Anyways, the context looks like: > > > > context "/person/show/3" do > > fixtures :people > > controller_name :person > > > > specify "should get person with id => 3 from model" do > > person = mock("person") > > > > > > Person.should_receive(:find).with("3").and_return(person) > > #Person.stub!(:find).with(person) > > get 'show', :id => 3 > > > > assigns(:person).should_be person > > end > > end > > OK - There's still a problem, and it turns out the problem is a bit sinister. > > Here's the test that exposes the problem: > > class EmptyClass > end > class SubclassOfEmptyClass > end > > def test_reset_proxied_methods_should_revert_to_original_when_method_already_exists_in_base_class > class << EmptyClass > def foobar > :original_value > end > end > SubclassOfEmptyClass.stub!(:foobar).with(:return_value) > SubclassOfEmptyClass.reset_proxied_methods! > assert :original_value, SubclassOfEmptyClass.foobar > end > > I've got that test committed and I'm working on the problem this > afternoon. I'll follow up when it's resovled! OK - this works now. I've committed the changes to the stubs branch. I'll follow up in a separate email re: next steps. David From aslak.hellesoy at gmail.com Tue Oct 3 17:47:09 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Tue, 3 Oct 2006 23:47:09 +0200 Subject: [rspec-devel] duplication of rails logic Message-ID: <8d961d900610031447t69f3bb3cjb86b5464cfdcbcb1@mail.gmail.com> hi folks, (especially brian, lachie and david who have spent most time in rspec on rails) my memory might be wrong here, but after brian implemented inherit and include in rspec core i thought we were able to get rid of a lot of the rails-setup code from rspec on rails (the code that sets up test requests, response, session and fixtures). looking at trunk i see that this code is actually now in two places - controller_mixin.rb and rspec_on_rails.rb (twice) on the stubbing branch this setup code looks like it's only in one place - context_eval.rb, which is better. it's no longer duplicated in our own codebase. but my question remains: do we really need to set up these objects in rspec at all? is my memory wrong when i'm saying that we once had none of this code - that the fact that we inherit from Test::Unit::TestCase we could get all of this setup code for free from rails' Test::Unit::TestCase extensions and not have to do this ourselves? cheers, aslak From dchelimsky at gmail.com Tue Oct 3 19:48:40 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 3 Oct 2006 18:48:40 -0500 Subject: [rspec-devel] duplication of rails logic In-Reply-To: <8d961d900610031447t69f3bb3cjb86b5464cfdcbcb1@mail.gmail.com> References: <8d961d900610031447t69f3bb3cjb86b5464cfdcbcb1@mail.gmail.com> Message-ID: <57c63afe0610031648r9d1d1f0o537ceff8991a5cc1@mail.gmail.com> On 10/3/06, aslak hellesoy wrote: > hi folks, > > (especially brian, lachie and david who have spent most time in rspec on rails) > > my memory might be wrong here, but after brian implemented inherit and > include in rspec core i thought we were able to get rid of a lot of > the rails-setup code from rspec on rails (the code that sets up test > requests, response, session and fixtures). > > looking at trunk i see that this code is actually now in two places - > controller_mixin.rb and rspec_on_rails.rb (twice) > > on the stubbing branch this setup code looks like it's only in one > place - context_eval.rb, which is better. it's no longer duplicated in > our own codebase. > > but my question remains: do we really need to set up these objects in > rspec at all? is my memory wrong when i'm saying that we once had none > of this code - that the fact that we inherit from Test::Unit::TestCase > we could get all of this setup code for free from rails' > Test::Unit::TestCase extensions and not have to do this ourselves? Assuming that this all lines up syntactically, we should definitely get rid of what we're already inheriting from Test::Unit. For tonight and tomorrow AM I'm focused on merging stubbing into the trunk. I may have time after that to look at this. David From dchelimsky at gmail.com Tue Oct 3 20:30:11 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 3 Oct 2006 19:30:11 -0500 Subject: [rspec-devel] stubbing/partial mocking Message-ID: <57c63afe0610031730u3d736aafs960ed6c28082abf0@mail.gmail.com> All, Brian Takita has been contributing to a stubs branch to support stubbing and partial mocking on Modules (and therefore classes). I tweaked the syntax a bit and merged it into the trunk, so you can update from the trunk and check out the new stubbing/mocking love. If you prefer to wait for a release, there should be one coming soon-ish (I'm aiming for later this week). As Brian pointed out in an earlier email, partial mocking is generally somewhat of a last resort, but it is very useful in some cases - like spec'ing rails controllers that interact with rails model classes: #stubbing - when you don't care about verification Person.stub!(:find).and_return(@person) #partial mocking: when you do care about verification Person.should_receive(:find).with("1").and_return(@person) This is not yet documented on the website - that will be happening over the next few days. Also, this does not preclude our slightly longer term goal of supporting the integration of other mocking/stubbing frameworks. That is in the works as well. Enjoy! And thanks to Brian for the excellent contributions. Cheers, David From dchelimsky at gmail.com Wed Oct 4 10:03:07 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 4 Oct 2006 09:03:07 -0500 Subject: [rspec-devel] do we need stubbing? Message-ID: <57c63afe0610040703o6216d340j5783110c325b07ef@mail.gmail.com> Hey all - The trunk currently supports three types of mocking/stubbing: Mock Objects (created dynamically at runtime) Partial Mocking of methods on existing classes Stubbing of methods on existing objects or classes The main difference between Partial Mocking and Stubbing is that Stubs don't verify. I'm wondering if we really need the stubbing facility at all, given that we can do the same thing using Partial Mocks. If we decided to yank the Stubs, we could add Partial Mocks support to objects (right now it only works on classes). Note that this functionality is not part of a release yet, so any such changes would only affect the brave trunk-dwellers among you. Any thoughts on this? Can anyone explain to me why stubs are useful in addition to partial mocks? David From dastels at daveastels.com Wed Oct 4 12:07:48 2006 From: dastels at daveastels.com (Dave Astels) Date: Wed, 4 Oct 2006 13:07:48 -0300 Subject: [rspec-devel] do we need stubbing? In-Reply-To: <57c63afe0610040703o6216d340j5783110c325b07ef@mail.gmail.com> References: <57c63afe0610040703o6216d340j5783110c325b07ef@mail.gmail.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4-Oct-06, at 11:03 AM, David Chelimsky wrote: > Any thoughts on this? Can anyone explain to me why stubs are useful in > addition to partial mocks? What is a stub? IMO it's a mock that is set to accept any number of calls with any arguments, with a set (or default) return value/action (i.e. raises a specific exception every time it's called). So, I can't (at the moment) see what we gain by having both. My advice would be to put stubs on the shelf until such time (if ever) that there is a proven need for them in addition to partial mocks. Dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFFI9xUauez/L4x7g4RApUDAJ9+Rc1P10Y+fP7oi8reT27d7+8G3wCfTFQ2 +IRDMqvktfCbzhvWHKBdWXU= =3t5l -----END PGP SIGNATURE----- From aslak.hellesoy at gmail.com Wed Oct 4 13:09:14 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Wed, 4 Oct 2006 19:09:14 +0200 Subject: [rspec-devel] [Rspec-users] do we need stubbing? In-Reply-To: <57c63afe0610040703o6216d340j5783110c325b07ef@mail.gmail.com> References: <57c63afe0610040703o6216d340j5783110c325b07ef@mail.gmail.com> Message-ID: <8d961d900610041009o5244f509iaf8899cd005c7baa@mail.gmail.com> On 10/4/06, David Chelimsky wrote: > Hey all - > > The trunk currently supports three types of mocking/stubbing: > > Mock Objects (created dynamically at runtime) > Partial Mocking of methods on existing classes > Stubbing of methods on existing objects or classes > > The main difference between Partial Mocking and Stubbing is that Stubs > don't verify. > > I'm wondering if we really need the stubbing facility at all, given > that we can do the same thing using Partial Mocks. If we decided to > yank the Stubs, we could add Partial Mocks support to objects (right > now it only works on classes). > Sounds good to me. Just to be precise - one or more methods could be mocked on an individual *Object* (Class is an Object). So this would work for any Object, not just Class. Right? I don't see a lot of value in stubbing without verification if partial mocking (or should we call it "object method mocking" to be more precise?) can be used on *any* object. > Note that this functionality is not part of a release yet, so any such > changes would only affect the brave trunk-dwellers among you. > > Any thoughts on this? Can anyone explain to me why stubs are useful in > addition to partial mocks? > I can't think of a compelling reason. Cheers, Aslak > David > _______________________________________________ > Rspec-users mailing list > Rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From jerry.west at ntlworld.com Wed Oct 4 13:28:30 2006 From: jerry.west at ntlworld.com (Jerry West) Date: Wed, 04 Oct 2006 18:28:30 +0100 Subject: [rspec-devel] Rails IntegrationTest and REL_0_6_3 Message-ID: <4523EF3E.6080509@ntlworld.com> This is how I integrated ActionController::IntegrationTest with the REL_0_6_3 rspec_on_rails plugin. Caveat - it works for me but I may have broken something I don't use. Is there a test suite for rspec_on_rails? I'd appreciate people checking it out, my controller specs are rather basic. Files also attached for convenience. 1. Edit spec/spec_helper.rb to delete the require of controller_mixin and to have SpecTestCase inherit from ActionController::IntegrationTest (which is itself a subclass of Test::Unit::TestCase). Note that I remove controller_mixin.rb altogether. Most of the file is superceded by IntegrationTest functionality and what little I need I put into rspec_on_rails.rb. I also found the extra level of indirection confusing! This is probably a philosophical argument and if the plugin authors feel it's necessary, no doubt it can be restored. 2. I also removed large chunks of rspec_on_rails.rb. Here's a (very briefly) annotated version of the attachment... require 'application' silence_warnings { RAILS_ENV = "test" } require 'active_record/fixtures' require 'action_controller/test_process' require 'action_controller/integration' require 'spec' module Spec module Runner # this comes from controller_mixin (Spec::ControllerContext) and is the only thing that does module ContextEval module ModuleMethods def controller_name(name=nil) @controller_name = name if name @controller_name end # from the original rspec_on_rails.rb; not sure about these, have'nt used/tested them def helper(name, &block) self.class.helper(name, &block) end def self.helper(name, &block) Spec::Runner::ExecutionContext.send :define_method, name.to_sym, &block end end # from the original, but remove everything that's now done by IntegrationTest module InstanceMethods attr_reader :controller def setup_with_controller(controller_name=nil) return unless controller_name @controller_class = "#{controller_name}_controller".camelize.constantize raise "Can't determine controller class for #{self.class}" if @controller_class.nil? @controller = @controller_class.new @controller_class.send(:define_method, :rescue_action) { |e| raise e } end # necessary to avoid the 'cache controller' problems of my first rspec-user email # basically, the cache is cleared by IntegrationTest::process (called by get, post etc) # but my specs didn't do any 'get's before testing the controller, so cache was invalid def teardown_with_controller ActionController::Base.clear_last_instantiation! if ActionController::Base.respond_to? :clear_last_instantiation! end end end # exactly as per the original... class Context module RailsPluginClassMethods def fixture_path @fixture_path ||= RAILS_ROOT + '/spec/fixtures' end attr_writer :fixture_path end extend RailsPluginClassMethods # entry point into rspec # Keep it sync'ed! super_run = instance_method(:run) define_method :run do |reporter, dry_run| controller_name = @context_eval_module.instance_eval {@controller_name} setup_method = proc do setup_with_controller(controller_name) end setup_parts.unshift setup_method teardown_method = proc do teardown_with_controller end teardown_parts.unshift teardown_method super_run.bind(self).call(reporter, dry_run) end end # Context end end # using assert_XX in specs causes an nil.add_assertion error which may be related to # the comment in IntegrationTest about Test::Unit::TestCase requiring at least one # test case(???hmmm). Anyway we 'fix' this by overriding the function that caused # the error (can you say 'hack'?) with no apparent side-effects but it has NOT been # extensively tested. If I knew what the assertion was being added to, I might offer # a better fix module Test module Unit class TestCase def add_assertion # overide Test::Unit::Case as we don't use that mechanism end end end end # IntegrationTest factored TestResponseBehaviour out from TestResponse, otherwise this # is much as per the original module ActionController # augment execution_context_class module TestResponseBehavior def render?(expected=nil) expected = expected.to_s unless expected.nil? # rendered_file(with_controller=false) [actionpack/lib/test_process.rb] rendered = expected ? rendered_file(!expected.include?('/')) : rendered_file expected.should_equal rendered # returns nil on success! true # error will have been raised otherwise end end end # and I re-wrote should_have_tag to make its use clearer, functionality is the same class String def should_have_tag(*opts) return false unless opts raise(ArgumentError, 'usage: should_have_tag(:tag => "tag", :contents => /Paul/)') unless opts.size <= 2 # accept first argument as String/Symbol tag if opts[0].is_a?(String) || opts[0].is_a?(Symbol) if opts[1] && opts[1].is_a?(Hash) # add it to subsequent hash opts = opts.last.merge({ :tag => opts.first.to_s }) else # turn it into a hash opts = { :tag => opts[0] } end else opts = opts.first # assume Hash end begin HTML::Document.new(self).find(opts).should_not_be_nil rescue self.should_include opts.inspect end end end # I first tried to replace this with assert_tag to avoid duplicating effort, but that went down # too many ratholes (including the nil.add_assertion call above). I still think it's worthwhile # having assertions available, but the response-based ones hook too deep for my liking (i.e. they # operate behind the scenes without any visible context from the specification). # this has gone in REL_0_6_4 but presumably has been replaced by something NilClass.sugarize_for_rspec! ------ If/when I have time, I'll try to make it work for REL_0_6_4; I'd appreciate some pointers about how to sugarize Nil though (unless it's now core - I haven't looked at the code yet). Best wishes, Jerry -------------- next part -------------- A non-text attachment was scrubbed... Name: spec_helper.rb Type: application/x-ruby Size: 654 bytes Desc: not available Url : http://rubyforge.org/pipermail/rspec-devel/attachments/20061004/1d22a6cd/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: rspec_on_rails.rb Type: application/x-ruby Size: 3622 bytes Desc: not available Url : http://rubyforge.org/pipermail/rspec-devel/attachments/20061004/1d22a6cd/attachment-0001.bin From dchelimsky at gmail.com Wed Oct 4 13:34:23 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 4 Oct 2006 12:34:23 -0500 Subject: [rspec-devel] [Rspec-users] String.should_hav_tag In-Reply-To: References: Message-ID: <57c63afe0610041034h5f312a6aibd79e6914784325d@mail.gmail.com> On 10/4/06, Micah Martin wrote: > I've just upgraded to rspec 0.6.4 and several specs were broken. All for > the same reason. String.should_have_tag doesn't seem to be supported any > longer. > > It used to be possible to write assertions like: > > response.body.should_have_tag :tag => "form" > > or > "".should_have_tag :tag => "body" > > But these fail with 0.6.4. The documentation still suggests this should > work. > > I was able to solve the problem by adding the following to my spec files: > > class String > include Spec::Expectations::TagExpectations > end Doh! Thanks for pointing this out Micah. This changed in this release and I neglected to point it out in the release notes. As of 0.6.4, instead of using this: response.body.should_have_tag you should use this: response.should_have_tag (see http://rspec.rubyforge.org/documentation/rails/rails.html) Micah's suggestion above will work in the short run, but I would recommend that you change the specs. In the next release (0.6.5) there will no longer be a module named Spec::Expectations::TagExpectations. Thanks, David ps - sorry for the inconvenience. It is our intent to NOT break backwards compatibility on any minor (0.6.x) releases or without any warning. From dchelimsky at gmail.com Wed Oct 4 15:36:56 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 4 Oct 2006 14:36:56 -0500 Subject: [rspec-devel] Rails IntegrationTest and REL_0_6_3 In-Reply-To: <4523EF3E.6080509@ntlworld.com> References: <4523EF3E.6080509@ntlworld.com> Message-ID: <57c63afe0610041236x871add9g7793de73f117e726@mail.gmail.com> On 10/4/06, Jerry West wrote: > This is how I integrated ActionController::IntegrationTest with the > REL_0_6_3 rspec_on_rails plugin. Caveat - it works for me but I may > have broken something I don't use. Is there a test suite for > rspec_on_rails? There are the beginnings of one in 0.6.4. rspec_on_rails is somewhat experimental, but we've included it in the releases because adventurers like yourself want to use it. Before we do a 1.0 release we're going to make sure there is a solid suite, but in the mean time things may be a little flaky as we try to nail down the API. > If/when I have time, I'll try to make it work for REL_0_6_4; I'd > appreciate some pointers about how to sugarize Nil though (unless it's > now core - I haven't looked at the code yet). NilClass.handle_underscores_for_rspec! From dchelimsky at gmail.com Wed Oct 4 15:44:03 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 4 Oct 2006 14:44:03 -0500 Subject: [rspec-devel] Rails IntegrationTest and REL_0_6_3 In-Reply-To: <4523EF3E.6080509@ntlworld.com> References: <4523EF3E.6080509@ntlworld.com> Message-ID: <57c63afe0610041244n591cceb9r4cc8ce25da6e9cd5@mail.gmail.com> On 10/4/06, Jerry West wrote: > Note that I remove controller_mixin.rb altogether. This is also removed in the trunk. Just an FYI - the rspec_on_rails plugin is very volitile right now. We're cleaning it up and it should stabilize over the next couple of releases, but any hacking you do into the structure pre 0.6.5 is likely break when that release comes out. Apologies if that presents an inconvenience in the short run, but we believe that the long term benefits will be worth it. Thanks, David From jay at jayfields.com Wed Oct 4 12:30:34 2006 From: jay at jayfields.com (Jay) Date: Wed, 4 Oct 2006 12:30:34 -0400 Subject: [rspec-devel] do we need stubbing? In-Reply-To: <57c63afe0610040703o6216d340j5783110c325b07ef@mail.gmail.com> References: <57c63afe0610040703o6216d340j5783110c325b07ef@mail.gmail.com> Message-ID: <24A4B825-C9F4-416B-B104-A46BA9637616@jayfields.com> I found that making mocks easy to use ended up removing my need for stubs. Since I've moved to using Mocha, I basically never use stubs anymore. my 2 cents. On Oct 4, 2006, at 10:03 AM, David Chelimsky wrote: > Hey all - > > The trunk currently supports three types of mocking/stubbing: > > Mock Objects (created dynamically at runtime) > Partial Mocking of methods on existing classes > Stubbing of methods on existing objects or classes > > The main difference between Partial Mocking and Stubbing is that Stubs > don't verify. > > I'm wondering if we really need the stubbing facility at all, given > that we can do the same thing using Partial Mocks. If we decided to > yank the Stubs, we could add Partial Mocks support to objects (right > now it only works on classes). > > Note that this functionality is not part of a release yet, so any such > changes would only affect the brave trunk-dwellers among you. > > Any thoughts on this? Can anyone explain to me why stubs are useful in > addition to partial mocks? > > David > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From noreply at rubyforge.org Wed Oct 4 13:37:51 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 4 Oct 2006 13:37:51 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-6017 ] rails plugin should ignore empty or non-existent spec-dirs Message-ID: <20061004173751.8AA8F52412CF@rubyforge.org> Feature Requests item #6017, was opened at 2006-10-04 17:37 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6017&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: David Chelimsky (dchelimsky) Summary: rails plugin should ignore empty or non-existent spec-dirs Initial Comment: [from Micah Martin to rspec-devel list] When running the spec rake task, if any of the folders 'spec/models', 'spec/controller', or 'spec/views' doesn't exist or if they don't contain any specs, the spec usage is printed. In my case I didn't have a views directory. I was able to get rid of the usage output by creating the views directory and adding a blank spec. It'd be convenient if RSpec would ignore missing/empty spec directories. BTW, thanks for the cool tool. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6017&group_id=797 From noreply at rubyforge.org Wed Oct 4 14:51:32 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 4 Oct 2006 14:51:32 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-5932 ] rspec_on_rails tied to gem Message-ID: <20061004185132.A3275524146A@rubyforge.org> Bugs item #5932, was opened at 2006-09-27 23:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=5932&group_id=797 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: David Chelimsky (dchelimsky) >Assigned to: Aslak Hellesoy (aslak_hellesoy) Summary: rspec_on_rails tied to gem Initial Comment: This is mostly for the dev team. stand in the root and do the following: cd vendor/rspec_on_rails rake pre_commit gem uninstall rspec (sudo if necessary, remove all versions) rake pre_commit What's happening is that pre_commit is bound to the spec command that is installed with the gem. With the gem uninstalled, these don't run. This means that whenever we're developing rspec_on_rails, we're developing against the last version of the gem we installed on our systems, not the current source. I'm just guessing, but I think that is bad! ---------------------------------------------------------------------- >Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-04 14:51 Message: Fixed! Added local rspec lib to LOAD_PATH in bootstrap_rspec.rb ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=5932&group_id=797 From noreply at rubyforge.org Wed Oct 4 17:07:43 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 4 Oct 2006 17:07:43 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-6017 ] rails plugin should ignore empty or non-existent spec-dirs Message-ID: <20061004210743.84A0D52417EC@rubyforge.org> Feature Requests item #6017, was opened at 2006-10-04 13:37 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6017&group_id=797 Category: None Group: None >Status: Closed Priority: 3 Submitted By: David Chelimsky (dchelimsky) >Assigned to: Aslak Hellesoy (aslak_hellesoy) Summary: rails plugin should ignore empty or non-existent spec-dirs Initial Comment: [from Micah Martin to rspec-devel list] When running the spec rake task, if any of the folders 'spec/models', 'spec/controller', or 'spec/views' doesn't exist or if they don't contain any specs, the spec usage is printed. In my case I didn't have a views directory. I was able to get rid of the usage output by creating the views directory and adding a blank spec. It'd be convenient if RSpec would ignore missing/empty spec directories. BTW, thanks for the cool tool. ---------------------------------------------------------------------- >Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-04 17:07 Message: Fixed on trunk. Will be in 0.6.5. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6017&group_id=797 From noreply at rubyforge.org Wed Oct 4 17:09:01 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 4 Oct 2006 17:09:01 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-6017 ] Rake task should ignore empty or non-existent spec-dirs Message-ID: <20061004210901.C47A552417B6@rubyforge.org> Feature Requests item #6017, was opened at 2006-10-04 13:37 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6017&group_id=797 Category: None Group: None Status: Closed Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Aslak Hellesoy (aslak_hellesoy) >Summary: Rake task should ignore empty or non-existent spec-dirs Initial Comment: [from Micah Martin to rspec-devel list] When running the spec rake task, if any of the folders 'spec/models', 'spec/controller', or 'spec/views' doesn't exist or if they don't contain any specs, the spec usage is printed. In my case I didn't have a views directory. I was able to get rid of the usage output by creating the views directory and adding a blank spec. It'd be convenient if RSpec would ignore missing/empty spec directories. BTW, thanks for the cool tool. ---------------------------------------------------------------------- >Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-04 17:09 Message: Fixed on trunk. Will be in 0.6.5. ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-04 17:07 Message: Fixed on trunk. Will be in 0.6.5. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6017&group_id=797 From brian.takita at gmail.com Wed Oct 4 21:53:01 2006 From: brian.takita at gmail.com (Brian Takita) Date: Wed, 4 Oct 2006 18:53:01 -0700 Subject: [rspec-devel] [Rspec-users] do we need stubbing? In-Reply-To: <8d961d900610041009o5244f509iaf8899cd005c7baa@mail.gmail.com> References: <57c63afe0610040703o6216d340j5783110c325b07ef@mail.gmail.com> <8d961d900610041009o5244f509iaf8899cd005c7baa@mail.gmail.com> Message-ID: <1d7ddd110610041853k2c3cc44ay7f938842d74ad3c5@mail.gmail.com> I like the Object#stub! method because it's syntax is more focused and clearer than using a mock for the purpose of stubbing a method. obj.stub!(:foobar).with(true) vs. obj.should_receive(:foobar).and_return(true).any_number_of_times The stub method also communicates my intention to stub out the method, just as mocking the method communicates my intention to verify that a certain message was passed to the object. I believe this makes my tests/specs clearer. Also, stub! is a method of Object. If we where to replace it with partial mocking, we would have to move partial mocking to Object to replace this behaviour. On 10/4/06, aslak hellesoy wrote: > > On 10/4/06, David Chelimsky wrote: > > Hey all - > > > > The trunk currently supports three types of mocking/stubbing: > > > > Mock Objects (created dynamically at runtime) > > Partial Mocking of methods on existing classes > > Stubbing of methods on existing objects or classes > > > > The main difference between Partial Mocking and Stubbing is that Stubs > > don't verify. > > > > I'm wondering if we really need the stubbing facility at all, given > > that we can do the same thing using Partial Mocks. If we decided to > > yank the Stubs, we could add Partial Mocks support to objects (right > > now it only works on classes). > > > > Sounds good to me. > > Just to be precise - one or more methods could be mocked on an > individual *Object* (Class is an Object). So this would work for any > Object, not just Class. Right? > > I don't see a lot of value in stubbing without verification if partial > mocking (or should we call it "object method mocking" to be more > precise?) can be used on *any* object. > > > Note that this functionality is not part of a release yet, so any such > > changes would only affect the brave trunk-dwellers among you. > > > > Any thoughts on this? Can anyone explain to me why stubs are useful in > > addition to partial mocks? > > > > I can't think of a compelling reason. > > Cheers, > Aslak > > > David > > _______________________________________________ > > Rspec-users mailing list > > Rspec-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-users > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061004/2e40efb1/attachment.html From brian.takita at gmail.com Wed Oct 4 21:55:08 2006 From: brian.takita at gmail.com (Brian Takita) Date: Wed, 4 Oct 2006 18:55:08 -0700 Subject: [rspec-devel] [Rspec-users] do we need stubbing? In-Reply-To: <1d7ddd110610041853k2c3cc44ay7f938842d74ad3c5@mail.gmail.com> References: <57c63afe0610040703o6216d340j5783110c325b07ef@mail.gmail.com> <8d961d900610041009o5244f509iaf8899cd005c7baa@mail.gmail.com> <1d7ddd110610041853k2c3cc44ay7f938842d74ad3c5@mail.gmail.com> Message-ID: <1d7ddd110610041855l2dbbe502ue4915c7612386b6e@mail.gmail.com> > > Also, stub! is a method of Object. If we where to replace it with partial > mocking, we would have to move partial mocking to Object to replace this > behaviour. Unless things have changed, partial mocking is a feature of Module objects. On 10/4/06, Brian Takita wrote: > > I like the Object#stub! method because it's syntax is more focused and > clearer than using a mock for the purpose of stubbing a method. > > obj.stub!(:foobar).with(true) > vs. > obj.should_receive(:foobar).and_return(true).any_number_of_times > > The stub method also communicates my intention to stub out the method, > just as mocking the method communicates my intention to verify that a > certain message was passed to the object. I believe this makes my > tests/specs clearer. > > Also, stub! is a method of Object. If we where to replace it with partial > mocking, we would have to move partial mocking to Object to replace this > behaviour. > > On 10/4/06, aslak hellesoy wrote: > > > > On 10/4/06, David Chelimsky wrote: > > > Hey all - > > > > > > The trunk currently supports three types of mocking/stubbing: > > > > > > Mock Objects (created dynamically at runtime) > > > Partial Mocking of methods on existing classes > > > Stubbing of methods on existing objects or classes > > > > > > The main difference between Partial Mocking and Stubbing is that Stubs > > > don't verify. > > > > > > I'm wondering if we really need the stubbing facility at all, given > > > that we can do the same thing using Partial Mocks. If we decided to > > > yank the Stubs, we could add Partial Mocks support to objects (right > > > now it only works on classes). > > > > > > > Sounds good to me. > > > > Just to be precise - one or more methods could be mocked on an > > individual *Object* (Class is an Object). So this would work for any > > Object, not just Class. Right? > > > > I don't see a lot of value in stubbing without verification if partial > > mocking (or should we call it "object method mocking" to be more > > precise?) can be used on *any* object. > > > > > Note that this functionality is not part of a release yet, so any such > > > > > changes would only affect the brave trunk-dwellers among you. > > > > > > Any thoughts on this? Can anyone explain to me why stubs are useful in > > > addition to partial mocks? > > > > > > > I can't think of a compelling reason. > > > > Cheers, > > Aslak > > > > > David > > > _______________________________________________ > > > Rspec-users mailing list > > > Rspec-users at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/rspec-users > > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061004/207f8d31/attachment-0001.html From shintaro at kakutani.com Thu Oct 5 07:07:22 2006 From: shintaro at kakutani.com (KAKUTANI Shintaro) Date: Thu, 05 Oct 2006 20:07:22 +0900 Subject: [rspec-devel] --colour with progress bar Message-ID: Hello, everyone. Thaks for RSpec 0.6.4 release and its '--color' option is great!! (I'm a grren bar lover.) I want to see colorized texts not only on summary line but on progress bar. Following patch represents what I want to : Index: progress_bar_formatter.rb =================================================================== --- progress_bar_formatter.rb (revision 855) +++ progress_bar_formatter.rb (working copy) @@ -8,12 +8,26 @@ end def spec_failed(name, counter, failure) - @output << 'F' + prompt = 'F' + if @colour && @output == STDOUT + colour_prefix = "\e[31m" + colour_postfix = "\e[0m" + else + colour_prefix = colour_postfix = "" + end + @output << "#{colour_prefix}#{prompt}#{colour_postfix}" @output.flush end def spec_passed(name) - @output << '.' + prompt = '.' + if @colour && @output == STDOUT + colour_prefix = "\e[32m" + colour_postfix = "\e[0m" + else + colour_prefix = colour_postfix = "" + end + @output << "#{colour_prefix}#{prompt}#{colour_postfix}" @output.flush end @@ -24,4 +38,4 @@ end end end -end \ No newline at end of file +end From noreply at rubyforge.org Thu Oct 5 03:02:50 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 5 Oct 2006 03:02:50 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-6027 ] rSpec for Rails fails on helper teardown if no teardown is defined within context Message-ID: <20061005070250.A9F795240A11@rubyforge.org> Bugs item #6027, was opened at 2006-10-05 10:02 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6027&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jan Wikholm (jwikholm) Assigned to: Nobody (None) Summary: rSpec for Rails fails on helper teardown if no teardown is defined within context Initial Comment: rSpec version 0.6.4 & corresponding rspec_for_rails I had a normal rspec generated by script/generate rspec_model company and had written specs for it. All specs pass otherwise but completely Fail on teardown, which is called from spec/spec_helper.rb(line 23) One example: 1) NoMethodError in 'A company (in general) should be invalid without a name' You have a nil object when you didn't expect it! You might have expected an instance of Array. The error occured while evaluating nil.- ./spec/models/../spec_helper.rb:23:in `teardown' That is same thing is printed for every specify block I have in my specs. After doing a simple: def teardown end in each context block the problem disappeared. It's not hard to fix it yourself, but I feel that defining an empty method for the sake of tests passing is not the way to go. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6027&group_id=797 From dchelimsky at gmail.com Thu Oct 5 09:29:33 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 5 Oct 2006 08:29:33 -0500 Subject: [rspec-devel] --colour with progress bar In-Reply-To: References: Message-ID: <57c63afe0610050629s60e2abd9o4da871fe1784552@mail.gmail.com> On 10/5/06, KAKUTANI Shintaro wrote: > Hello, everyone. > > Thaks for RSpec 0.6.4 release and its '--color' option is great!! > (I'm a grren bar lover.) > > I want to see colorized texts not only on summary line but on progress bar. > Following patch represents what I want to : > > Index: progress_bar_formatter.rb > =================================================================== > --- progress_bar_formatter.rb (revision 855) > +++ progress_bar_formatter.rb (working copy) > @@ -8,12 +8,26 @@ > end > > def spec_failed(name, counter, failure) > - @output << 'F' > + prompt = 'F' > + if @colour && @output == STDOUT > + colour_prefix = "\e[31m" > + colour_postfix = "\e[0m" > + else > + colour_prefix = colour_postfix = "" > + end > + @output << "#{colour_prefix}#{prompt}#{colour_postfix}" > @output.flush > end > > def spec_passed(name) > - @output << '.' > + prompt = '.' > + if @colour && @output == STDOUT > + colour_prefix = "\e[32m" > + colour_postfix = "\e[0m" > + else > + colour_prefix = colour_postfix = "" > + end > + @output << "#{colour_prefix}#{prompt}#{colour_postfix}" > @output.flush > end > > @@ -24,4 +38,4 @@ > end > end > end > -end > \ No newline at end of file > +end How about sticking this in a custom formatter? spec spec -f MyCustomFormatter --require my_custom_formatter.rb From jerry.west at ntlworld.com Thu Oct 5 09:41:09 2006 From: jerry.west at ntlworld.com (Jerry West) Date: Thu, 05 Oct 2006 14:41:09 +0100 Subject: [rspec-devel] Rails IntegrationTest and REL_0_6_3 In-Reply-To: <57c63afe0610041244n591cceb9r4cc8ce25da6e9cd5@mail.gmail.com> References: <4523EF3E.6080509@ntlworld.com> <57c63afe0610041244n591cceb9r4cc8ce25da6e9cd5@mail.gmail.com> Message-ID: <45250B75.2000806@ntlworld.com> Okay, I'll leave well alone. Can I help write tests or anything? Rgds, Jerry David Chelimsky wrote: > On 10/4/06, Jerry West wrote: > >> Note that I remove controller_mixin.rb altogether. >> > > This is also removed in the trunk. > > Just an FYI - the rspec_on_rails plugin is very volitile right now. > We're cleaning it up and it should stabilize over the next couple of > releases, but any hacking you do into the structure pre 0.6.5 is > likely break when that release comes out. > > Apologies if that presents an inconvenience in the short run, but we > believe that the long term benefits will be worth it. > > Thanks, > David > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From brian.takita at gmail.com Thu Oct 5 12:43:55 2006 From: brian.takita at gmail.com (Brian Takita) Date: Thu, 5 Oct 2006 09:43:55 -0700 Subject: [rspec-devel] [Rspec-users] do we need stubbing? In-Reply-To: <1d7ddd110610041855l2dbbe502ue4915c7612386b6e@mail.gmail.com> References: <57c63afe0610040703o6216d340j5783110c325b07ef@mail.gmail.com> <8d961d900610041009o5244f509iaf8899cd005c7baa@mail.gmail.com> <1d7ddd110610041853k2c3cc44ay7f938842d74ad3c5@mail.gmail.com> <1d7ddd110610041855l2dbbe502ue4915c7612386b6e@mail.gmail.com> Message-ID: <1d7ddd110610050943x2f62b30dv4570d1481a0d3b66@mail.gmail.com> I talked with David last night. We agreed to make the stub! method quivalent to the expectation: obj.should_receive(:foobar).any_number_of_times So instead of: obj.stub!(:foobar).with(true) one would use: obj.stub!(:foobar).and_return(true) Does adding the stub! method to Mock sound good? class Mock def stub!(method_name) return should_receive(method_name).any_number_of_times end end Thanks for leaving in the stub! method. Brian On 10/4/06, Brian Takita wrote: > > Also, stub! is a method of Object. If we where to replace it with partial > > mocking, we would have to move partial mocking to Object to replace this > > behaviour. > > > Unless things have changed, partial mocking is a feature of Module > objects. > > > On 10/4/06, Brian Takita wrote: > > > > I like the Object#stub! method because it's syntax is more focused and > > clearer than using a mock for the purpose of stubbing a method. > > > > obj.stub!(:foobar).with(true) > > vs. > > obj.should_receive(:foobar).and_return(true).any_number_of_times > > > > The stub method also communicates my intention to stub out the method, > > just as mocking the method communicates my intention to verify that a > > certain message was passed to the object. I believe this makes my > > tests/specs clearer. > > > > Also, stub! is a method of Object. If we where to replace it with > > partial mocking, we would have to move partial mocking to Object to replace > > this behaviour. > > > > On 10/4/06, aslak hellesoy wrote: > > > > > > On 10/4/06, David Chelimsky wrote: > > > > Hey all - > > > > > > > > The trunk currently supports three types of mocking/stubbing: > > > > > > > > Mock Objects (created dynamically at runtime) > > > > Partial Mocking of methods on existing classes > > > > Stubbing of methods on existing objects or classes > > > > > > > > The main difference between Partial Mocking and Stubbing is that > > > Stubs > > > > don't verify. > > > > > > > > I'm wondering if we really need the stubbing facility at all, given > > > > that we can do the same thing using Partial Mocks. If we decided to > > > > yank the Stubs, we could add Partial Mocks support to objects (right > > > > > > > now it only works on classes). > > > > > > > > > > Sounds good to me. > > > > > > Just to be precise - one or more methods could be mocked on an > > > individual *Object* (Class is an Object). So this would work for any > > > Object, not just Class. Right? > > > > > > I don't see a lot of value in stubbing without verification if partial > > > mocking (or should we call it "object method mocking" to be more > > > precise?) can be used on *any* object. > > > > > > > Note that this functionality is not part of a release yet, so any > > > such > > > > changes would only affect the brave trunk-dwellers among you. > > > > > > > > Any thoughts on this? Can anyone explain to me why stubs are useful > > > in > > > > addition to partial mocks? > > > > > > > > > > I can't think of a compelling reason. > > > > > > Cheers, > > > Aslak > > > > > > > David > > > > _______________________________________________ > > > > Rspec-users mailing list > > > > Rspec-users at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/rspec-users > > > > > > > _______________________________________________ > > > rspec-devel mailing list > > > rspec-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061005/4a0c3597/attachment.html From dchelimsky at gmail.com Thu Oct 5 13:02:38 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 5 Oct 2006 12:02:38 -0500 Subject: [rspec-devel] [Rspec-users] do we need stubbing? In-Reply-To: <1d7ddd110610050943x2f62b30dv4570d1481a0d3b66@mail.gmail.com> References: <57c63afe0610040703o6216d340j5783110c325b07ef@mail.gmail.com> <8d961d900610041009o5244f509iaf8899cd005c7baa@mail.gmail.com> <1d7ddd110610041853k2c3cc44ay7f938842d74ad3c5@mail.gmail.com> <1d7ddd110610041855l2dbbe502ue4915c7612386b6e@mail.gmail.com> <1d7ddd110610050943x2f62b30dv4570d1481a0d3b66@mail.gmail.com> Message-ID: <57c63afe0610051002i6c83e7bbk44c9893e1e8561a7@mail.gmail.com> On 10/5/06, Brian Takita wrote: > I talked with David last night. We agreed to make the stub! method quivalent > to the expectation: > obj.should_receive(:foobar).any_number_of_times > > So instead of: > obj.stub!(:foobar).with(true) > > one would use: > obj.stub!(:foobar).and_return(true) > > Does adding the stub! method to Mock sound good? > > class Mock > def stub!(method_name) > return should_receive(method_name).any_number_of_times > end > end That's more or less what I did. Basically there is a MockInstanceMethods module with should_receive, should_not_receive and stub!. This gets included in Mock and Object and becomes the entry point for all mocking (complete, partial) and stubbing. It's committed to the trunk, so please check it out and have a look. I'm pretty psyched about it. David > > Thanks for leaving in the stub! method. > > Brian > > > On 10/4/06, Brian Takita wrote: > > > > > Also, stub! is a method of Object. If we where to replace it with > partial mocking, we would have to move partial mocking to Object to replace > this behaviour. > > > > > > Unless things have changed, partial mocking is a feature of Module > objects. > > > > > > > > > > On 10/4/06, Brian Takita wrote: > > > I like the Object#stub! method because it's syntax is more focused and > clearer than using a mock for the purpose of stubbing a method. > > > > > > obj.stub!(:foobar).with(true) > > > vs. > > > > obj.should_receive(:foobar).and_return(true).any_number_of_times > > > > > > The stub method also communicates my intention to stub out the method, > just as mocking the method communicates my intention to verify that a > certain message was passed to the object. I believe this makes my > tests/specs clearer. > > > > > > Also, stub! is a method of Object. If we where to replace it with > partial mocking, we would have to move partial mocking to Object to replace > this behaviour. > > > > > > > > > > > > On 10/4/06, aslak hellesoy wrote: > > > > On 10/4/06, David Chelimsky wrote: > > > > > Hey all - > > > > > > > > > > The trunk currently supports three types of mocking/stubbing: > > > > > > > > > > Mock Objects (created dynamically at runtime) > > > > > Partial Mocking of methods on existing classes > > > > > Stubbing of methods on existing objects or classes > > > > > > > > > > The main difference between Partial Mocking and Stubbing is that > Stubs > > > > > don't verify. > > > > > > > > > > I'm wondering if we really need the stubbing facility at all, given > > > > > that we can do the same thing using Partial Mocks. If we decided to > > > > > yank the Stubs, we could add Partial Mocks support to objects (right > > > > > now it only works on classes). > > > > > > > > > > > > > Sounds good to me. > > > > > > > > Just to be precise - one or more methods could be mocked on an > > > > individual *Object* (Class is an Object). So this would work for any > > > > Object, not just Class. Right? > > > > > > > > I don't see a lot of value in stubbing without verification if partial > > > > mocking (or should we call it "object method mocking" to be more > > > > precise?) can be used on *any* object. > > > > > > > > > Note that this functionality is not part of a release yet, so any > such > > > > > changes would only affect the brave trunk-dwellers among you. > > > > > > > > > > Any thoughts on this? Can anyone explain to me why stubs are useful > in > > > > > addition to partial mocks? > > > > > > > > > > > > > I can't think of a compelling reason. > > > > > > > > Cheers, > > > > Aslak > > > > > > > > > David > > > > > _______________________________________________ > > > > > Rspec-users mailing list > > > > > Rspec-users at rubyforge.org > > > > > http://rubyforge.org/mailman/listinfo/rspec-users > > > > > > > > > _______________________________________________ > > > > rspec-devel mailing list > > > > rspec-devel at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > > > > From dchelimsky at gmail.com Thu Oct 5 13:22:48 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 5 Oct 2006 12:22:48 -0500 Subject: [rspec-devel] Rails IntegrationTest and REL_0_6_3 In-Reply-To: <45250B75.2000806@ntlworld.com> References: <4523EF3E.6080509@ntlworld.com> <57c63afe0610041244n591cceb9r4cc8ce25da6e9cd5@mail.gmail.com> <45250B75.2000806@ntlworld.com> Message-ID: <57c63afe0610051022k2a3760d4yf61e9bb80535ed4e@mail.gmail.com> On 10/5/06, Jerry West wrote: > Okay, I'll leave well alone. Can I help write tests or anything? Sure. What do you have in mind? > > Rgds, > Jerry > > David Chelimsky wrote: > > On 10/4/06, Jerry West wrote: > > > >> Note that I remove controller_mixin.rb altogether. > >> > > > > This is also removed in the trunk. > > > > Just an FYI - the rspec_on_rails plugin is very volitile right now. > > We're cleaning it up and it should stabilize over the next couple of > > releases, but any hacking you do into the structure pre 0.6.5 is > > likely break when that release comes out. > > > > Apologies if that presents an inconvenience in the short run, but we > > believe that the long term benefits will be worth it. > > > > Thanks, > > David > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dgoodlad at gmail.com Thu Oct 5 15:44:55 2006 From: dgoodlad at gmail.com (David Goodlad) Date: Thu, 5 Oct 2006 12:44:55 -0700 Subject: [rspec-devel] [Rspec-users] do we need stubbing? In-Reply-To: <57c63afe0610051002i6c83e7bbk44c9893e1e8561a7@mail.gmail.com> References: <57c63afe0610040703o6216d340j5783110c325b07ef@mail.gmail.com> <8d961d900610041009o5244f509iaf8899cd005c7baa@mail.gmail.com> <1d7ddd110610041853k2c3cc44ay7f938842d74ad3c5@mail.gmail.com> <1d7ddd110610041855l2dbbe502ue4915c7612386b6e@mail.gmail.com> <1d7ddd110610050943x2f62b30dv4570d1481a0d3b66@mail.gmail.com> <57c63afe0610051002i6c83e7bbk44c9893e1e8561a7@mail.gmail.com> Message-ID: I'm joining this conversation late (and adding yet another 'David' to the list of participants!), but I just thought I'd chime in... On 10/5/06, David Chelimsky wrote: > On 10/5/06, Brian Takita wrote: > > I talked with David last night. We agreed to make the stub! method quivalent > > to the expectation: > > obj.should_receive(:foobar).any_number_of_times > > > > So instead of: > > obj.stub!(:foobar).with(true) > > > > one would use: > > obj.stub!(:foobar).and_return(true) +1; Why have the duplicated code, when the stub really ends up meaning an unverified mock... Looks great to me. > > > > Does adding the stub! method to Mock sound good? > > > > class Mock > > def stub!(method_name) > > return should_receive(method_name).any_number_of_times > > end > > end > > That's more or less what I did. Basically there is a > MockInstanceMethods module with should_receive, should_not_receive and > stub!. This gets included in Mock and Object and becomes the entry > point for all mocking (complete, partial) and stubbing. > > It's committed to the trunk, so please check it out and have a look. > I'm pretty psyched about it. I love what I'm seeing in the stub-/mock-ing department in rspec. It's making my specs so much clearer and easier to work with. Dave -- Dave Goodlad dgoodlad at gmail.com or dave at goodlad.ca http://david.goodlad.ca/ From shintaro at kakutani.com Thu Oct 5 21:23:20 2006 From: shintaro at kakutani.com (KAKUTANI Shintaro) Date: Fri, 06 Oct 2006 10:23:20 +0900 Subject: [rspec-devel] --colour with progress bar In-Reply-To: <57c63afe0610050629s60e2abd9o4da871fe1784552@mail.gmail.com> References: <57c63afe0610050629s60e2abd9o4da871fe1784552@mail.gmail.com> Message-ID: Hi, At Thu, 5 Oct 2006 08:29:33 -0500, David Chelimsky wrote: > > How about sticking this in a custom formatter? > I was expected to see colored text on both a result summary and a progress bar when my first running spec command with -c option. That's not unnatural expectation to me. and Test::Unit with RedGreen supports that feature. > spec spec -f MyCustomFormatter --require my_custom_formatter.rb I'll try that. Thanks! Sincerely, -- { :name: ["KAKUTANI", "Shintaro"], :email: shintaro at kakutani.com, :website: http://kakutani.com/ } From david at davelee.com.au Sat Oct 7 09:45:59 2006 From: david at davelee.com.au (David Lee) Date: Sat, 7 Oct 2006 23:45:59 +1000 Subject: [rspec-devel] Rails: tracking Edge or Stable release? (found bug on edge) Message-ID: <71210F0C-E2B2-4643-AACC-5865F9AD86D6@davelee.com.au> Hi, I've been tracking RSpec and using it exclusively for a new project. I've found a great deal to like about it. I ran into a mysterious issue while functional testing on edge rails, which resulted in my losing a couple of hours and reporting this ticket (RSpec with Rails: skip_before_filter is ignored on edge rails): http://rubyforge.org/tracker/index.php? func=detail&aid=6053&group_id=797&atid=3149 I'd like to know if RSpec is 'supposed' to be tracking edge, or just the latest stable release (or both), so i can adjust my development setup and bug reporting habits accordingly. thanks for the great tool, all involved cheers, David From dchelimsky at gmail.com Sat Oct 7 15:10:32 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 7 Oct 2006 14:10:32 -0500 Subject: [rspec-devel] Rails: tracking Edge or Stable release? (found bug on edge) In-Reply-To: <71210F0C-E2B2-4643-AACC-5865F9AD86D6@davelee.com.au> References: <71210F0C-E2B2-4643-AACC-5865F9AD86D6@davelee.com.au> Message-ID: <57c63afe0610071210v5eca9fe4g4dbf2a6b316b50e7@mail.gmail.com> On 10/7/06, David Lee wrote: > Hi, > > I've been tracking RSpec and using it exclusively for a new project. > I've found a great deal to like about it. > > I ran into a mysterious issue while functional testing on edge rails, > which resulted in my losing a couple of hours and reporting this > ticket (RSpec with Rails: skip_before_filter is ignored on edge rails): > > http://rubyforge.org/tracker/index.php? > func=detail&aid=6053&group_id=797&atid=3149 > > I'd like to know if RSpec is 'supposed' to be tracking edge, or just > the latest stable release (or both), so i can adjust my development > setup and bug reporting habits accordingly. While rspec core is fairly stable at this point, rspec_on_rails has a way to go and will remain volitile for a little bit. That said, feel free to raise any bugs you wish. Even if we don't get to them right away we want to know what's going on, and in the long run we want rspec_on_rails to be a flat out better choice than test/unit for those interested in BDD and even those TDD'ers who just long for better separation between model, controller and view specs. As far as edge rails is concerned, we don't have a formal policy about this yet but we should have one before we release 1.0 (which I am hoping will happen before the end of the year). My current thinking is that, given that all of the committers are fortunate to be working full time jobs, we'll likely not commit to keeping up w/ edge rails, but that we'll always try to support the latest rails release as of our release. That seems fair and feasible to me. > > thanks for the great tool, all involved Thanks for using it and expressing your interest in it. Cheers, David > > cheers, > David > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From noreply at rubyforge.org Sat Oct 7 09:36:27 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 7 Oct 2006 09:36:27 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-6053 ] RSpec with Rails: skip_before_filter is ignored on edge rails Message-ID: <20061007133627.6DA0A5240CDE@rubyforge.org> Bugs item #6053, was opened at 2006-10-07 09:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6053&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: RSpec with Rails: skip_before_filter is ignored on edge rails Initial Comment: RSpec on Rails ignores skip_before_filter declarations in controllers being tested with RSpec. Appears to be non-issue with Rails 1.1.6. Broken on edge rails. Example code: # application.rb: class ApplicationController < ActionController::Base before_filter :raise_error def raise_error raise "This should never be called" end end # example_controller.rb class ExampleController < ApplicationController skip_before_filter :raise_error def tester render :text => 'hello world' end end # example_controller_spec.rb => raises error require File.dirname(__FILE__) + '/../spec_helper' context "The ExampleController" do controller_name :example specify "Should skip before_filter :raise_error" do get :tester response.should_be_success end end # example_controller_spec.rb => reports success require File.dirname(__FILE__) + '/../test_helper' require 'example_controller' # Re-raise errors caught by the controller. class ExampleController; def rescue_action(e) raise e end; end class ExampleControllerTest < Test::Unit::TestCase def setup @controller = ExampleController.new @request = ActionController::TestRequest.new @response = ActionController::TestResponse.new end # Replace this with your real tests. def test_no_error_without_rspec get :tester assert_response :success end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6053&group_id=797 From noreply at rubyforge.org Sat Oct 7 17:33:58 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 7 Oct 2006 17:33:58 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-6056 ] Multiple output of failing-spec notice Message-ID: <20061007213358.6225AA970025@rubyforge.org> Bugs item #6056, was opened at 2006-10-07 14:33 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6056&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Sam Livingston-Gray (geeksam) Assigned to: Nobody (None) Summary: Multiple output of failing-spec notice Initial Comment: Using RSpec 0.6.4, running the following specs: context 'A failing context' do specify 'should fail' do true.should_be false end end context 'A different context just minding its own business' do specify 'should pass' do true.should_be true end end Produces this output: F 1) Spec::Expectations::ExpectationNotMetError in 'A failing context should fail' true should be false rspec_bug.rb:7:in `should fail' rspec_bug.rb:5 Finished in 0.015 seconds 1 specification, 1 failure F. 1) Spec::Expectations::ExpectationNotMetError in 'A failing context should fail' true should be false rspec_bug.rb:7:in `should fail' rspec_bug.rb:5 2) Spec::Expectations::ExpectationNotMetError in 'A failing context should fail' true should be false rspec_bug.rb:7:in `should fail' rspec_bug.rb:17 Finished in 0.0 seconds 3 specifications, 2 failures ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6056&group_id=797 From noreply at rubyforge.org Sat Oct 7 17:36:15 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 7 Oct 2006 17:36:15 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-6057 ] strange test output on windows Message-ID: <20061007213615.DCF05524118A@rubyforge.org> Bugs item #6057, was opened at 2006-10-07 21:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6057&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: alan maybourne (nothingmuch) Assigned to: Nobody (None) Summary: strange test output on windows Initial Comment: on my windows box, when I run a spec, it incorrectly reports the number of specifications. Here's the output from stack_spec.rb in the tutorial (this is all from just running the spec once - it looks as though it's being run multiple times..?): C:\WINDOWS\system32\cmd.exe /c ruby stack_spec.rb -f s A new stack - should be empty Finished in 0.0 seconds 1 specification, 0 failures A new stack - should be empty An empty stack - should not be empty after 'push' Finished in 0.0 seconds 3 specifications, 0 failures A new stack - should be empty An empty stack - should not be empty after 'push' A stack with one item - should return top when you send it 'top' Finished in 0.0 seconds 6 specifications, 0 failures Hit any key to close this window... I didn't change the source code at all from what's available in the tutorial. I also wrote my own very simple class and spec and found the same bug. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6057&group_id=797 From noreply at rubyforge.org Sat Oct 7 17:37:30 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 7 Oct 2006 17:37:30 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-6057 ] strange test output on windows Message-ID: <20061007213730.40A1AA970007@rubyforge.org> Bugs item #6057, was opened at 2006-10-07 21:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6057&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: alan maybourne (nothingmuch) Assigned to: Nobody (None) Summary: strange test output on windows Initial Comment: on my windows box, when I run a spec, it incorrectly reports the number of specifications. Here's the output from stack_spec.rb in the tutorial (this is all from just running the spec once - it looks as though it's being run multiple times..?): C:\WINDOWS\system32\cmd.exe /c ruby stack_spec.rb -f s A new stack - should be empty Finished in 0.0 seconds 1 specification, 0 failures A new stack - should be empty An empty stack - should not be empty after 'push' Finished in 0.0 seconds 3 specifications, 0 failures A new stack - should be empty An empty stack - should not be empty after 'push' A stack with one item - should return top when you send it 'top' Finished in 0.0 seconds 6 specifications, 0 failures Hit any key to close this window... I didn't change the source code at all from what's available in the tutorial. I also wrote my own very simple class and spec and found the same bug. ---------------------------------------------------------------------- >Comment By: alan maybourne (nothingmuch) Date: 2006-10-07 21:37 Message: I forgot to mention, I'm running rspec 0.6.4 and ruby 1.8.4 on windows xp ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6057&group_id=797 From david at davelee.com.au Sat Oct 7 20:49:40 2006 From: david at davelee.com.au (David Lee) Date: Sun, 8 Oct 2006 10:49:40 +1000 Subject: [rspec-devel] Rails: tracking Edge or Stable release? (found bug on edge) In-Reply-To: <57c63afe0610071210v5eca9fe4g4dbf2a6b316b50e7@mail.gmail.com> References: <71210F0C-E2B2-4643-AACC-5865F9AD86D6@davelee.com.au> <57c63afe0610071210v5eca9fe4g4dbf2a6b316b50e7@mail.gmail.com> Message-ID: <0C4165AD-7F19-4952-A008-F58C46B78C2B@davelee.com.au> Sounds like a pretty fair deal, thanks. I'll use stable Rails for now. Maybe I'll learn enough about RSpec's internals in the meantime that if / when i need to use edge I can do something more useful than just scream when i see a bug. Look forward to seeing it come along. cheers David Lee On 08/10/2006, at 5:10 AM, David Chelimsky wrote: > > While rspec core is fairly stable at this point, rspec_on_rails has a > way to go and will remain volitile for a little bit. That said, feel > free to raise any bugs you wish. Even if we don't get to them right > away we want to know what's going on, and in the long run we want > rspec_on_rails to be a flat out better choice than test/unit for those > interested in BDD and even those TDD'ers who just long for better > separation between model, controller and view specs. > > As far as edge rails is concerned, we don't have a formal policy about > this yet but we should have one before we release 1.0 (which I am > hoping will happen before the end of the year). My current thinking is > that, given that all of the committers are fortunate to be working > full time jobs, we'll likely not commit to keeping up w/ edge rails, > but that we'll always try to support the latest rails release as of > our release. That seems fair and feasible to me. > >> >> thanks for the great tool, all involved > > Thanks for using it and expressing your interest in it. > > Cheers, > David > >> >> cheers, >> David >> >> >> _______________________________________________ >> rspec-devel mailing list >> rspec-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-devel >> > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From noreply at rubyforge.org Sat Oct 7 21:10:46 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 7 Oct 2006 21:10:46 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-6058 ] should_have_tag should support "", "name" and :name Message-ID: <20061008011046.EF855A97002A@rubyforge.org> Feature Requests item #6058, was opened at 2006-10-08 01:10 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6058&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: David Chelimsky (dchelimsky) Summary: should_have_tag should support "", "name" and :name Initial Comment: should_have_tag should support "", "name" and :name Right now it only supports "name" ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6058&group_id=797 From noreply at rubyforge.org Sat Oct 7 21:14:37 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 7 Oct 2006 21:14:37 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-6057 ] strange test output on windows Message-ID: <20061008011437.8A3E6A97002A@rubyforge.org> Bugs item #6057, was opened at 2006-10-07 21:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6057&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: alan maybourne (nothingmuch) Assigned to: Nobody (None) Summary: strange test output on windows Initial Comment: on my windows box, when I run a spec, it incorrectly reports the number of specifications. Here's the output from stack_spec.rb in the tutorial (this is all from just running the spec once - it looks as though it's being run multiple times..?): C:\WINDOWS\system32\cmd.exe /c ruby stack_spec.rb -f s A new stack - should be empty Finished in 0.0 seconds 1 specification, 0 failures A new stack - should be empty An empty stack - should not be empty after 'push' Finished in 0.0 seconds 3 specifications, 0 failures A new stack - should be empty An empty stack - should not be empty after 'push' A stack with one item - should return top when you send it 'top' Finished in 0.0 seconds 6 specifications, 0 failures Hit any key to close this window... I didn't change the source code at all from what's available in the tutorial. I also wrote my own very simple class and spec and found the same bug. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-10-08 01:14 Message: This is a bug that occurs when you run using the ruby command rather than the spec command. If you do the following you shouldn't see it: C:\WINDOWS\system32\cmd.exe /c spec stack_spec.rb -f s Still, we'll leave this open and address it in the context of the ruby command. ---------------------------------------------------------------------- Comment By: alan maybourne (nothingmuch) Date: 2006-10-07 21:37 Message: I forgot to mention, I'm running rspec 0.6.4 and ruby 1.8.4 on windows xp ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6057&group_id=797 From noreply at rubyforge.org Sat Oct 7 21:54:25 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 7 Oct 2006 21:54:25 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-6059 ] Controller testing w/ Rails: response is not upated when same action is GETted multiple times within a specify block Message-ID: <20061008015425.11D48A970020@rubyforge.org> Bugs item #6059, was opened at 2006-10-08 11:54 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6059&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: David Lee (davidlee) Assigned to: Nobody (None) Summary: Controller testing w/ Rails: response is not upated when same action is GETted multiple times within a specify block Initial Comment: Controller testing with RSpec + Rails: response is not upated within a specification when same action is called multiple times within a specify block using Rails 1.1.6 and RSpec 0.6.4 The response object is not being updated within a specify block if multiple responses are generated by GETting the same action. This was verified by checking the redirect_url reported. This does not appear to be an issue unless the *same action* is called multiple times within a specify block, eg to test the effect of accessing an action with different permissions or parameters. Calling the action with different parameters did not appear to affect the problem. example: specify "Index should redirect to welcome if already logged in" do # this will redirect to login as user is not logged in. # the presence of this line will break the test. get :index request.session[:user] = 1 # subsequent gets will redirect to welcome # this will be ignored with regard to the response.redirect_url reported get :index response.should_redirect # fails if first line is present: # says the redirect_url equals 'http://test.host/account/login' # which is a leftover from the first get :index response.redirect_url.should_equal 'http://test.host/account/welcome' end breaking the two `get :index` calls out into separate specify blocks alleviates the problem. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6059&group_id=797 From noreply at rubyforge.org Mon Oct 9 06:31:14 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 9 Oct 2006 06:31:14 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-6071 ] script/rails_spec causes MissingSourceFile error Message-ID: <20061009103114.230D35240F94@rubyforge.org> Bugs item #6071, was opened at 2006-10-09 10:31 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6071&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: alan maybourne (nothingmuch) Assigned to: Nobody (None) Summary: script/rails_spec causes MissingSourceFile error Initial Comment: Windows XP Pro Ruby 1.8.4 Rails 1.1.6 rspec 0.6.4 I can successfully start the rspec server which gives the message "loading Rails Environment" followed by "Ready" but when I then try to use the rails_spec command here's what I get ----- C:\rails\morgan>ruby script/rails_spec reminder_spec.rb -f s c:/ruby/lib/ruby/1.8/drb/drb.rb:1090:in `method_missing': MissingSourceFile (DRb ::DRbUnknownError) from script/rails_spec:8 C:\rails\morgan> ----- running the spec on it's own using the spec command works fine ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6071&group_id=797 From aslak.hellesoy at gmail.com Tue Oct 10 21:11:50 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Wed, 11 Oct 2006 03:11:50 +0200 Subject: [rspec-devel] Retiring test2spec? Message-ID: <8d961d900610101811q26555cc6v55523a1a63d3971a@mail.gmail.com> Hi all, We're thinking about retiring the test2spec translation tool because it's becoming a maintenance problem. Is anyone using it? Would anyone miss it if it went away? Aslak From aslak.hellesoy at gmail.com Tue Oct 10 21:27:05 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Wed, 11 Oct 2006 03:27:05 +0200 Subject: [rspec-devel] dogfood time? Message-ID: <8d961d900610101827p54a27367od82480b5d6bcc63e@mail.gmail.com> A while ago I brought up the idea of making RSpec self-hosting. I.e. completely ditch RSpec's own Test::Unit tests and use RSpec to verify itself during the build process. One of the counter arguments that came up (I think it was Dave) was "what if we have bugs that get masked". I think that at this point RSpec core is mature enough to make it worth the risk. I think the risk of having masked bugs is minimal - I think we'd discover it quickly if it happened. What do you think? Is it time to trust our own tool and eat our own dogfood? (We'd check in the test2spec generated translations, reformat them and delete the Test::Unit tests plus test2spec) Aslak From noreply at rubyforge.org Tue Oct 10 22:10:42 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 10 Oct 2006 22:10:42 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-6091 ] should_raise should match error messages Message-ID: <20061011021042.2AC35A97001A@rubyforge.org> Feature Requests item #6091, was opened at 2006-10-11 02:10 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6091&group_id=797 Category: mock module Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: should_raise should match error messages Initial Comment: context "the should_raise expectation" do specify "should accept and verify an expected message using equality" do lambda do raise 'Hello' end.should_raise(StandardError).with_message "Hello" end specify "should accept and verify an expected message using regex matching" do lambda do raise 'Hello' end.should_raise(StandardError).with_message_matching /ello/ end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6091&group_id=797 From dastels at daveastels.com Wed Oct 11 04:29:27 2006 From: dastels at daveastels.com (Dave Astels) Date: Wed, 11 Oct 2006 05:29:27 -0300 Subject: [rspec-devel] dogfood time? In-Reply-To: <8d961d900610101827p54a27367od82480b5d6bcc63e@mail.gmail.com> References: <8d961d900610101827p54a27367od82480b5d6bcc63e@mail.gmail.com> Message-ID: <22A2E499-6587-4341-9C0F-3DF4A4E00888@daveastels.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10-Oct-06, at 10:27 PM, aslak hellesoy wrote: > A while ago I brought up the idea of making RSpec self-hosting. I.e. > completely ditch RSpec's own Test::Unit tests and use RSpec to verify > itself during the build process. > > One of the counter arguments that came up (I think it was Dave) was > "what if we have bugs that get masked". > > I think that at this point RSpec core is mature enough to make it > worth the risk. I think the risk of having masked bugs is minimal - I > think we'd discover it quickly if it happened. > > What do you think? Is it time to trust our own tool and eat our own > dogfood? > (We'd check in the test2spec generated translations, reformat them and > delete the Test::Unit tests plus test2spec) I think you're right that it's ready for that now. +1 Dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFFLKtnauez/L4x7g4RAjA3AKCSAj8gc4YmfxJAkfW/O/lAn5reDgCgvkdY rA3wdlGYaoOAVnO/TelmUJk= =yX79 -----END PGP SIGNATURE----- From dastels at daveastels.com Wed Oct 11 04:30:04 2006 From: dastels at daveastels.com (Dave Astels) Date: Wed, 11 Oct 2006 05:30:04 -0300 Subject: [rspec-devel] Retiring test2spec? In-Reply-To: <8d961d900610101811q26555cc6v55523a1a63d3971a@mail.gmail.com> References: <8d961d900610101811q26555cc6v55523a1a63d3971a@mail.gmail.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10-Oct-06, at 10:11 PM, aslak hellesoy wrote: > Hi all, > > We're thinking about retiring the test2spec translation tool because > it's becoming a maintenance problem. +1 Dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFFLKuNauez/L4x7g4RAqw3AJ4rbyOgeMi/bXIuVWRVT1oNimNZZACcCMVM zILoLwKNAENWkkVCwjUSnrQ= =eQfn -----END PGP SIGNATURE----- From noreply at rubyforge.org Wed Oct 11 00:45:45 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 11 Oct 2006 00:45:45 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-6094 ] rspec_on_rails pre-commit fails w/ -b option turned off Message-ID: <20061011044545.B2CD45240AA2@rubyforge.org> Bugs item #6094, was opened at 2006-10-11 04:45 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6094&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: rspec_on_rails pre-commit fails w/ -b option turned off Initial Comment: This is in the trunk as of revision 868. Go to ~/vendor/rspec_on_rails/lib/tasks/bootstrap_rspec.rake and remove or comment the line that reads: t.spec_opts = ['-b'] Stand in ~/vendor/rspec_on-rails and execute: ../../bin/spec spec ../../bin/spec specs Everything should pass Now try this: rake pre_commit You'll get the following error (or similar): 1) NoMethodError in 'Given an rjs call to insert html in a div, a 'should_not_have_rjs' spec with no text but wrong element name should pass' You have a nil object when you didn't expect it! You might have expected an instance of Array. The error occured while evaluating nil.size generated_code/routing/generation.rb:30:in `generate_default_path' ./specs/should_not_have_rjs_spec.rb:99:in `setup' /Users/david/projects/ruby/rspec-all/trunk/vendor/rspec_on_rails/vendor/plugins/rspec/lib/extensions/spec/runner/context.rb:30:in `run' ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6094&group_id=797 From noreply at rubyforge.org Wed Oct 11 03:30:12 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 11 Oct 2006 03:30:12 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-6095 ] Arbitrary operators do not all work, as per tutorial Message-ID: <20061011073012.5C09F5240CB7@rubyforge.org> Bugs item #6095, was opened at 2006-10-11 03:30 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6095&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: Arbitrary operators do not all work, as per tutorial Initial Comment: In version 0.6.3, writing a specification such as, @setup_variable.attribute.should_be > 0 where attribute returns a comparable object (in the case I was testing, a Fixnum), fails with a message complaining about method >? missing from the returned object. I have yet to test this on 0.6.4, yet, so I am unsure whether it has been fixed between the two versions. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6095&group_id=797 From noreply at rubyforge.org Wed Oct 11 06:01:42 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 11 Oct 2006 06:01:42 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-6098 ] Make scaffold_resource generator Message-ID: <20061011100142.327EB5240EF2@rubyforge.org> Feature Requests item #6098, was opened at 2006-10-11 06:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6098&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Aslak Hellesoy (aslak_hellesoy) Assigned to: Nobody (None) Summary: Make scaffold_resource generator Initial Comment: In the new RESTful Rails it's better to use the scaffold_resource generator. We should support it too. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6098&group_id=797 From dchelimsky at gmail.com Wed Oct 11 15:25:31 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 11 Oct 2006 15:25:31 -0400 Subject: [rspec-devel] Retiring test2spec? In-Reply-To: References: <8d961d900610101811q26555cc6v55523a1a63d3971a@mail.gmail.com> Message-ID: <57c63afe0610111225v7e471c49l3d64aef336a6f265@mail.gmail.com> On 10/11/06, Dave Astels wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On 10-Oct-06, at 10:11 PM, aslak hellesoy wrote: > > > Hi all, > > > > We're thinking about retiring the test2spec translation tool because > > it's becoming a maintenance problem. > > +1 > > Dave +1 David From dchelimsky at gmail.com Wed Oct 11 15:28:53 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 11 Oct 2006 15:28:53 -0400 Subject: [rspec-devel] dogfood time? In-Reply-To: <22A2E499-6587-4341-9C0F-3DF4A4E00888@daveastels.com> References: <8d961d900610101827p54a27367od82480b5d6bcc63e@mail.gmail.com> <22A2E499-6587-4341-9C0F-3DF4A4E00888@daveastels.com> Message-ID: <57c63afe0610111228n1dab0b83y10a2837e62d68054@mail.gmail.com> On 10/11/06, Dave Astels wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On 10-Oct-06, at 10:27 PM, aslak hellesoy wrote: > > > A while ago I brought up the idea of making RSpec self-hosting. I.e. > > completely ditch RSpec's own Test::Unit tests and use RSpec to verify > > itself during the build process. > > > > One of the counter arguments that came up (I think it was Dave) was > > "what if we have bugs that get masked". > > > > I think that at this point RSpec core is mature enough to make it > > worth the risk. I think the risk of having masked bugs is minimal - I > > think we'd discover it quickly if it happened. > > > > What do you think? Is it time to trust our own tool and eat our own > > dogfood? > > (We'd check in the test2spec generated translations, reformat them and > > delete the Test::Unit tests plus test2spec) > > I think you're right that it's ready for that now. > > +1 +1 One word of caution on this. There are test/unit tests that don't get translated in the build because they test things like the ability of partial mocks to attach themselves to the Specification that is current running. When running a Specification INSIDE a Specification, the mocks attach themselves to the wrong spec. So this area will need to be restructured such that we can translate all of the specs before we follow through on this. That said, I love the idea of rspec spec'ing itself. From noreply at rubyforge.org Wed Oct 11 11:39:25 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 11 Oct 2006 11:39:25 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-6095 ] Arbitrary operators do not all work, as per tutorial Message-ID: <20061011153925.0B34E5241218@rubyforge.org> Bugs item #6095, was opened at 2006-10-11 07:30 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6095&group_id=797 Category: None Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: Arbitrary operators do not all work, as per tutorial Initial Comment: In version 0.6.3, writing a specification such as, @setup_variable.attribute.should_be > 0 where attribute returns a comparable object (in the case I was testing, a Fixnum), fails with a message complaining about method >? missing from the returned object. I have yet to test this on 0.6.4, yet, so I am unsure whether it has been fixed between the two versions. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-10-11 15:39 Message: This feature was added to rspec 0.6.4, so it is not expected to work with 0.6.3. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6095&group_id=797 From noreply at rubyforge.org Wed Oct 11 14:09:27 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 11 Oct 2006 14:09:27 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-6095 ] Arbitrary operators do not all work, as per tutorial Message-ID: <20061011180927.A3D2D5241469@rubyforge.org> Bugs item #6095, was opened at 2006-10-11 00:30 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6095&group_id=797 Category: None Group: None Status: Closed Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: Arbitrary operators do not all work, as per tutorial Initial Comment: In version 0.6.3, writing a specification such as, @setup_variable.attribute.should_be > 0 where attribute returns a comparable object (in the case I was testing, a Fixnum), fails with a message complaining about method >? missing from the returned object. I have yet to test this on 0.6.4, yet, so I am unsure whether it has been fixed between the two versions. ---------------------------------------------------------------------- Comment By: Joshua Bowers (joshuabowers) Date: 2006-10-11 11:09 Message: Ah. Thank you for the update! I'll get around to updating, then. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-10-11 08:39 Message: This feature was added to rspec 0.6.4, so it is not expected to work with 0.6.3. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6095&group_id=797 From dchelimsky at gmail.com Wed Oct 11 17:53:39 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 11 Oct 2006 17:53:39 -0400 Subject: [rspec-devel] stubbing/mocking Message-ID: <57c63afe0610111453x37fcbc3awc46e70ac4d732dd3@mail.gmail.com> All, Inspired by a conversation on the mocha list, I added the ability to mix stubs w/ mocks on the same methods. Here's what it allows: context "a mock" do specify "can stub! and mock the same message" do mock = mock("stubbing mock") mock.stub!(:msg).and_return(:stub_value) mock.should_receive(:msg).with(:arg).and_return(:mock_value) mock.msg.should_equal :stub_value mock.msg(:other_arg).should_equal :stub_value mock.msg(:arg).should_equal :mock_value mock.msg(:another_arg).should_equal :stub_value mock.msg(:yet_another_arg).should_equal :stub_value mock.msg.should_equal :stub_value end end Basically, the stub will be invoked for any calls to :msg without :arg. Does this seem useful? Check out the trunk if you think so and give it a shot. Thanks, David From dastels at daveastels.com Wed Oct 11 19:05:57 2006 From: dastels at daveastels.com (Dave Astels) Date: Wed, 11 Oct 2006 20:05:57 -0300 Subject: [rspec-devel] stubbing/mocking In-Reply-To: <57c63afe0610111453x37fcbc3awc46e70ac4d732dd3@mail.gmail.com> References: <57c63afe0610111453x37fcbc3awc46e70ac4d732dd3@mail.gmail.com> Message-ID: <397160EB-17B5-446F-89E4-7FE1A56C0FB6@daveastels.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11-Oct-06, at 6:53 PM, David Chelimsky wrote: > All, > > Inspired by a conversation on the mocha list, I added the ability to > mix stubs w/ mocks on the same methods. > ... > Does this seem useful? Check out the trunk if you think so and give > it a shot. Sounds like it could be... set a default with stub! and the interesting specific cases with mocks Dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFFLXjWauez/L4x7g4RAsmrAJoD+QVP6LXRXDtdDJC/r/r2jId9IACgkAw4 RJdSN7jVDLCc4N483EYn/Mw= =WQc3 -----END PGP SIGNATURE----- From brian.takita at gmail.com Thu Oct 12 01:07:17 2006 From: brian.takita at gmail.com (Brian Takita) Date: Wed, 11 Oct 2006 22:07:17 -0700 Subject: [rspec-devel] stubbing/mocking In-Reply-To: <397160EB-17B5-446F-89E4-7FE1A56C0FB6@daveastels.com> References: <57c63afe0610111453x37fcbc3awc46e70ac4d732dd3@mail.gmail.com> <397160EB-17B5-446F-89E4-7FE1A56C0FB6@daveastels.com> Message-ID: <1d7ddd110610112207g4b1ec636l1e58fe4deb5f6900@mail.gmail.com> +1 On 10/11/06, Dave Astels wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On 11-Oct-06, at 6:53 PM, David Chelimsky wrote: > > > All, > > > > Inspired by a conversation on the mocha list, I added the ability to > > mix stubs w/ mocks on the same methods. > > ... > > Does this seem useful? Check out the trunk if you think so and give > > it a shot. > > Sounds like it could be... set a default with stub! and the > interesting specific cases with mocks > > Dave > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.3 (Darwin) > > iD8DBQFFLXjWauez/L4x7g4RAsmrAJoD+QVP6LXRXDtdDJC/r/r2jId9IACgkAw4 > RJdSN7jVDLCc4N483EYn/Mw= > =WQc3 > -----END PGP SIGNATURE----- > _______________________________________________ > 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/20061011/c0156bac/attachment.html From malavoi at gmail.com Thu Oct 12 07:27:08 2006 From: malavoi at gmail.com (Bolo Michelin) Date: Thu, 12 Oct 2006 07:27:08 -0400 Subject: [rspec-devel] Rpec with Locomo Message-ID: <5fa283580610120427q7c0472e2ic91ea93eeabd9644@mail.gmail.com> Hello I turn off transactional_fixture self.use_transactional_fixtures = false But when i tested rcpec have this error pc-mq-dsi3:~/Documents/Coding-Dev/expay_corporate bmichelin$ spec spec/models/faq_spec.rb /Applications/Locomotive2/Bundles/standardRailsSept2006.locobundle/i386/lib/ruby/gems/1.8/gems/sqlite3- ruby-1.1.0/lib/sqlite3/errors.rb:94:in `check': cannot rollback - no transaction is active (SQLite3::SQLException) thanks -- Bolo Michelin web: http://www.independza.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061012/852641c6/attachment.html From david at davelee.com.au Thu Oct 12 08:06:28 2006 From: david at davelee.com.au (David Lee) Date: Thu, 12 Oct 2006 22:06:28 +1000 Subject: [rspec-devel] Postgresql Warnings (was Re: Rpec with Locomo In-Reply-To: <5fa283580610120427q7c0472e2ic91ea93eeabd9644@mail.gmail.com> References: <5fa283580610120427q7c0472e2ic91ea93eeabd9644@mail.gmail.com> Message-ID: <9CBBE7FC-9F3E-4D45-9904-5E3855FF5792@davelee.com.au> It may be worth mentioning I get plenty of warnings with Postgresql and RSpec about transactions when i run my specs - this for each specify block: WARNING: there is no transaction in progress .WARNING: there is already a transaction in progress /opt/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/ active_record/validations.rb:300: warning: Object#type is deprecated; use Object#class /opt/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/ active_record/validations.rb:300: warning: Object#type is deprecated; use Object#class /opt/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/ active_record/validations.rb:300: warning: Object#type is deprecated; use Object#class /opt/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/ active_record/validations.rb:300: warning: Object#type is deprecated; use Object#class /opt/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/ active_record/validations.rb:300: warning: Object#type is deprecated; use Object#class WARNING: there is no transaction in progress cheers, David On 12/10/2006, at 9:27 PM, Bolo Michelin wrote: > Hello > > I turn off transactional_fixture > self.use_transactional_fixtures = false > > But when i tested rcpec have this error > > pc-mq-dsi3:~/Documents/Coding-Dev/expay_corporate bmichelin$ spec > spec/models/faq_spec.rb > > /Applications/Locomotive2/Bundles/standardRailsSept2006.locobundle/ > i386/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.1.0/lib/sqlite3/ > errors.rb:94:in `check': cannot rollback - no transaction is active > (SQLite3::SQLException) > > thanks > > -- > Bolo Michelin > web: http://www.independza.com > _______________________________________________ > 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/20061012/257fa88f/attachment.html From aslak.hellesoy at gmail.com Thu Oct 12 09:51:13 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Thu, 12 Oct 2006 15:51:13 +0200 Subject: [rspec-devel] Postgresql Warnings (was Re: Rpec with Locomo In-Reply-To: <9CBBE7FC-9F3E-4D45-9904-5E3855FF5792@davelee.com.au> References: <5fa283580610120427q7c0472e2ic91ea93eeabd9644@mail.gmail.com> <9CBBE7FC-9F3E-4D45-9904-5E3855FF5792@davelee.com.au> Message-ID: <8d961d900610120651x33ea2392tdced1681ab75b4a1@mail.gmail.com> Feel free to post a bug report with a description (attach some files) about how to reproduce this behaviour. Aslak On 10/12/06, David Lee wrote: > It may be worth mentioning I get plenty of warnings with Postgresql and > RSpec about transactions when i run my specs - this for each specify block: > > WARNING: there is no transaction in progress > .WARNING: there is already a transaction in progress > /opt/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/validations.rb:300: > warning: Object#type is deprecated; use Object#class > /opt/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/validations.rb:300: > warning: Object#type is deprecated; use Object#class > /opt/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/validations.rb:300: > warning: Object#type is deprecated; use Object#class > /opt/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/validations.rb:300: > warning: Object#type is deprecated; use Object#class > /opt/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/validations.rb:300: > warning: Object#type is deprecated; use Object#class > WARNING: there is no transaction in progress > > > cheers, > David > > > On 12/10/2006, at 9:27 PM, Bolo Michelin wrote: > Hello > > I turn off transactional_fixture > self.use_transactional_fixtures = false > > But when i tested rcpec have this error > > pc-mq-dsi3:~/Documents/Coding-Dev/expay_corporate > bmichelin$ spec spec/models/faq_spec.rb > > /Applications/Locomotive2/Bundles/standardRailsSept2006.locobundle/i386/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.1.0/lib/sqlite3/errors.rb:94:in > `check': cannot rollback - no transaction is active (SQLite3::SQLException) > > thanks > > -- > Bolo Michelin > web: http://www.independza.com > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > From david at davelee.com.au Thu Oct 12 10:30:48 2006 From: david at davelee.com.au (David Lee) Date: Fri, 13 Oct 2006 00:30:48 +1000 Subject: [rspec-devel] Postgresql Warnings (was Re: Rpec with Locomo In-Reply-To: <8d961d900610120651x33ea2392tdced1681ab75b4a1@mail.gmail.com> References: <5fa283580610120427q7c0472e2ic91ea93eeabd9644@mail.gmail.com> <9CBBE7FC-9F3E-4D45-9904-5E3855FF5792@davelee.com.au> <8d961d900610120651x33ea2392tdced1681ab75b4a1@mail.gmail.com> Message-ID: <9C290351-F650-4BA6-9706-729D89F00FFF@davelee.com.au> ok, I will post a bug report. I won't post a file, as it seems to happen for any rails model specs running on Postgresql (verified on Arch Linux and OS X with both a "real" and a fresh, blank project). I suspect my issue and the sqlite one posted below might share a common cause: both seem to point to an issue in handling transactions properly - possibly transactions being nested when they should not be? Just a semi-na?ve guess ... cheers, David On 12/10/2006, at 11:51 PM, aslak hellesoy wrote: > Feel free to post a bug report with a description (attach some files) > about how to reproduce this behaviour. > > Aslak > > On 10/12/06, David Lee wrote: >> It may be worth mentioning I get plenty of warnings with >> Postgresql and >> RSpec about transactions when i run my specs - this for each >> specify block: >> >> WARNING: there is no transaction in progress >> .WARNING: there is already a transaction in progress >> /opt/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/ >> active_record/validations.rb:300: >> warning: Object#type is deprecated; use Object#class >> /opt/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/ >> active_record/validations.rb:300: >> warning: Object#type is deprecated; use Object#class >> /opt/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/ >> active_record/validations.rb:300: >> warning: Object#type is deprecated; use Object#class >> /opt/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/ >> active_record/validations.rb:300: >> warning: Object#type is deprecated; use Object#class >> /opt/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/ >> active_record/validations.rb:300: >> warning: Object#type is deprecated; use Object#class >> WARNING: there is no transaction in progress >> >> >> cheers, >> David >> >> >> On 12/10/2006, at 9:27 PM, Bolo Michelin wrote: >> Hello >> >> I turn off transactional_fixture >> self.use_transactional_fixtures = false >> >> But when i tested rcpec have this error >> >> pc-mq-dsi3:~/Documents/Coding-Dev/expay_corporate >> bmichelin$ spec spec/models/faq_spec.rb >> >> /Applications/Locomotive2/Bundles/standardRailsSept2006.locobundle/ >> i386/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.1.0/lib/sqlite3/ >> errors.rb:94:in >> `check': cannot rollback - no transaction is active >> (SQLite3::SQLException) >> >> thanks >> >> -- >> Bolo Michelin >> web: http://www.independza.com >> _______________________________________________ >> rspec-devel mailing list >> rspec-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-devel >> >> _______________________________________________ >> rspec-devel mailing list >> rspec-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-devel >> >> > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From dgoodlad at gmail.com Thu Oct 12 14:53:11 2006 From: dgoodlad at gmail.com (David Goodlad) Date: Thu, 12 Oct 2006 11:53:11 -0700 Subject: [rspec-devel] [ rspec-Feature Requests-6098 ] Make scaffold_resource generator In-Reply-To: <20061011100142.327EB5240EF2@rubyforge.org> References: <20061011100142.327EB5240EF2@rubyforge.org> Message-ID: On 10/11/06, noreply at rubyforge.org wrote: > Feature Requests item #6098, was opened at 2006-10-11 06:01 > You can respond by visiting: > http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6098&group_id=797 > > Category: None > Group: None > Status: Open > Priority: 3 > Submitted By: Aslak Hellesoy (aslak_hellesoy) > Assigned to: Nobody (None) > Summary: Make scaffold_resource generator > > Initial Comment: > In the new RESTful Rails it's better to use the scaffold_resource generator. We should support it too. I've just finished building a restful controller generator with specs this morning, actually. It doesn't have pre-defined views, because we don't want them here at work, but they could be easily added. The specs are imho fairly comprehensive and descriptive. Should I try to get permission to post it publicly? Would it fill this need? Dave -- Dave Goodlad dgoodlad at gmail.com or dave at goodlad.ca http://david.goodlad.ca/ From dastels at daveastels.com Thu Oct 12 16:34:53 2006 From: dastels at daveastels.com (Dave Astels) Date: Thu, 12 Oct 2006 17:34:53 -0300 Subject: [rspec-devel] [ rspec-Feature Requests-6098 ] Make scaffold_resource generator In-Reply-To: References: <20061011100142.327EB5240EF2@rubyforge.org> Message-ID: On 12-Oct-06, at 3:53 PM, David Goodlad wrote: > I've just finished building a restful controller generator with specs > this morning, actually. It doesn't have pre-defined views, because we > don't want them here at work, but they could be easily added. The > specs are imho fairly comprehensive and descriptive. > > Should I try to get permission to post it publicly? Would it fill > this need? Hey David, IMO that would be awesome. The more good examples that are accessible, the better. Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061012/881716b5/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://rubyforge.org/pipermail/rspec-devel/attachments/20061012/881716b5/attachment.bin From aslak.hellesoy at gmail.com Thu Oct 12 16:47:59 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Thu, 12 Oct 2006 22:47:59 +0200 Subject: [rspec-devel] [ rspec-Feature Requests-6098 ] Make scaffold_resource generator In-Reply-To: References: <20061011100142.327EB5240EF2@rubyforge.org> Message-ID: <8d961d900610121347h75620133s9f3f63c0d455d2d3@mail.gmail.com> On 10/12/06, David Goodlad wrote: > On 10/11/06, noreply at rubyforge.org wrote: > > Feature Requests item #6098, was opened at 2006-10-11 06:01 > > You can respond by visiting: > > http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6098&group_id=797 > > > > Category: None > > Group: None > > Status: Open > > Priority: 3 > > Submitted By: Aslak Hellesoy (aslak_hellesoy) > > Assigned to: Nobody (None) > > Summary: Make scaffold_resource generator > > > > Initial Comment: > > In the new RESTful Rails it's better to use the scaffold_resource generator. We should support it too. > > I've just finished building a restful controller generator with specs > this morning, actually. It doesn't have pre-defined views, because we > don't want them here at work, but they could be easily added. The > specs are imho fairly comprehensive and descriptive. > > Should I try to get permission to post it publicly? Would it fill this need? > That would be great. If you get legal clearance for it, please post the code as an attatchment to the RFE above. > Dave > > -- > Dave Goodlad > dgoodlad at gmail.com or dave at goodlad.ca > http://david.goodlad.ca/ > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From malavoi at gmail.com Thu Oct 12 16:56:00 2006 From: malavoi at gmail.com (Bolo Michelin) Date: Thu, 12 Oct 2006 16:56:00 -0400 Subject: [rspec-devel] Rpec with Locomo In-Reply-To: <5fa283580610120427q7c0472e2ic91ea93eeabd9644@mail.gmail.com> References: <5fa283580610120427q7c0472e2ic91ea93eeabd9644@mail.gmail.com> Message-ID: <5fa283580610121356x675d7f44pa96e389185c53e59@mail.gmail.com> Nobody ? my spec.file require File.dirname(__FILE__) + '/../spec_helper' module FaqSpecHelper def validate_faq_attributes { :question_fr => 'titre de la question', :response_fr => 'reponse de la question'} end end context "une faq en g?n?ral" do def setup @faq = Faq.new end specify "devras ?tre invalide sans question" do #doit avoir une r?ponse valide @faq.reponse_fr = 'le_titre_de_la_question' @faq.should_not_be_valid @faq.errors.on(:question_fr).should_equal "est necessaire" @faq.question_fr = 'le_titre_de_la_question' @faq.should_be_valid end specify "devras ?tre invalide sans r?ponse" do #doit avoir une question valide @faq.question_fr = 'le_titre_de_la_question' @faq.should_not_be_valid @faq.errors.on(:reponse_fr).should_equal "est necessaire" @faq.reponse_fr = 'le_titre_de_la_question' @faq.should_be_valid end end 2006/10/12, Bolo Michelin : > > Hello > > I turn off transactional_fixture > self.use_transactional_fixtures = false > > But when i tested rcpec have this error > > pc-mq-dsi3:~/Documents/Coding-Dev/expay_corporate bmichelin$ spec > spec/models/faq_spec.rb > > > /Applications/Locomotive2/Bundles/standardRailsSept2006.locobundle/i386/lib/ruby/gems/1.8/gems/sqlite3- > ruby-1.1.0/lib/sqlite3/errors.rb:94:in `check': cannot rollback - no > transaction is active (SQLite3::SQLException) > > thanks > > -- > Bolo Michelin > web: http://www.independza.com -- Bolo Michelin web: http://www.independza.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061012/db2821c3/attachment.html From daniel at dr-siemssen.de Thu Oct 12 17:09:55 2006 From: daniel at dr-siemssen.de (Daniel Siemssen) Date: Thu, 12 Oct 2006 23:09:55 +0200 Subject: [rspec-devel] [ rspec-Feature Requests-6098 ] Make scaffold_resource generator In-Reply-To: References: <20061011100142.327EB5240EF2@rubyforge.org> Message-ID: <452EAF23.6040404@dr-siemssen.de> On 12.10.2006 22:34, Dave Astels wrote: > > On 12-Oct-06, at 3:53 PM, David Goodlad wrote: > >> I've just finished building a restful controller generator with specs >> >> this morning, actually. It doesn't have pre-defined views, because we >> >> don't want them here at work, but they could be easily added. The >> >> specs are imho fairly comprehensive and descriptive. >> >> >> Should I try to get permission to post it publicly? Would it fill >> this need? >> > > Hey David, > > IMO that would be awesome. The more good examples that are > accessible, the better. > > Dave > Hi, Here are some "restful" specs (the controllers, models and views are not generated using scaffold_resource but they are similar to scaffold_resource's output): https://cvsdude.com/trac/railfrog/cms/browser/branches/PRE_0.6/vendor/railfrog_plugins/gems/fucd_rbac-0.0.1/spec https://cvsdude.com/trac/railfrog/cms/browser/branches/PRE_0.6/vendor/railfrog_plugins/gems/fucd_rbac-0.0.1/app Maybe not good examples but they might be of help to someone... Daniel > ------------------------------------------------------------------------ > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From noreply at rubyforge.org Thu Oct 12 10:35:00 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 12 Oct 2006 10:35:00 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-6112 ] Rspec on Rails: Postgresql reports WARNING: there is already a transaction in progress Message-ID: <20061012143501.3910A5241833@rubyforge.org> Bugs item #6112, was opened at 2006-10-13 00:35 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6112&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: David Lee (davidlee) Assigned to: Nobody (None) Summary: Rspec on Rails: Postgresql reports WARNING: there is already a transaction in progress Initial Comment: This has been verified on Arch Linux (gimmick) and OS X Tiger (postgres 8.1 via darwinports), using Rails 1.1.2 and RSpec 0.6.4 & the rspec rails plugin. Description (output from skeletal rails project): /tmp/foo % spec spec/models/tester_spec.rb WARNING: there is already a transaction in progress WARNING: there is no transaction in progress .WARNING: there is already a transaction in progress WARNING: there is no transaction in progress F 1) Spec::Expectations::ExpectationNotMetError in 'Tester class with fixtures loaded should have more specifications' not enough specs ./spec/models/tester_spec.rb:11:in `should have more specifications' Finished in 0.326214 seconds 2 specifications, 1 failure ____ 2 lines of warnings are generated per specify block. When running a substantial spec, voluminous WARNINGs are generated, such that it is necessary to run spec spec/models/* 2> /dev/null to prevent the test output being lost in noise. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6112&group_id=797 From noreply at rubyforge.org Thu Oct 12 07:25:37 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 12 Oct 2006 07:25:37 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-5064 ] Let mock() take a class argument Message-ID: <20061012112537.B5644A97001B@rubyforge.org> Feature Requests item #5064, was opened at 2006-07-14 21:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5064&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Aslak Hellesoy (aslak_hellesoy) Assigned to: Nobody (None) Summary: Let mock() take a class argument Initial Comment: I'd like to start my development by using: thing = mock("thing") Once I have discovered thing's interface, I'd like to switch to: thing = mock(Thing) The idea is that should_expect would fail as long as Thing doesn't implement the expected method. This is a great way to go to the next step - implementing the Thing interface. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-10-12 11:25 Message: I've been thinking about this a bit and I'd like to take it even further. The thing that bugs me about this idea is that I have to keep track of which mocks are using a name and which are using the Class. What if we started creating an empty Thing class and wrote this: thing = mock(Thing) That would run if the class exists, but it not yet be defined in any detail. Then we could run specs in varying modes. Normally, they would run as they do now, with the exception that the mock expectation would read "Mock expected...." or something like that. A second mode, invoked w/ a command line option, would be that it does the checking that you talk about to make sure that all the messages being mocked have corresponding methods on the real class. A third mode would be something someone proposed on the email list - an integration mode. This would require some additional setup and I'm not sure what that looks like (perhaps an integration_setup block?), but the idea is that you could run all of the same specs using real objects instead of the mocks. You wouldn't have to write separate integration specs. This is something Dan described about JBehave when he and I spoke at Agile 06. When you run JBehave, it tells you how many mocks are still being used. The idea there is that you should remove them over time - just use them to get you there, but use the real objects as they come to be. When there are no mocks in the run and all the specs pass, you're done! The nice thing about having a CL option to run them this way is that you can monitor your progress towards "done", but you can also run the specs in isolation normally. This gives you the benefits of both worlds - isolation and integration. In fact the mock modes could be isolation (default), verification and integration. That has some nice symmetry to it. Thoughts? David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5064&group_id=797 From dgoodlad at gmail.com Thu Oct 12 19:52:34 2006 From: dgoodlad at gmail.com (David Goodlad) Date: Thu, 12 Oct 2006 16:52:34 -0700 Subject: [rspec-devel] [ rspec-Feature Requests-6098 ] Make scaffold_resource generator In-Reply-To: <8d961d900610121347h75620133s9f3f63c0d455d2d3@mail.gmail.com> References: <20061011100142.327EB5240EF2@rubyforge.org> <8d961d900610121347h75620133s9f3f63c0d455d2d3@mail.gmail.com> Message-ID: Hi Aslak (and Dave - can only 'reply' to one message) > > Should I try to get permission to post it publicly? Would it fill this need? > > > > That would be great. If you get legal clearance for it, please post > the code as an attatchment to the RFE above. Will do. I just added some basic views to the generator, but they don't automatically add fields like the normal scaffolding: I prefer to set that up by hand... I'll talk to my boss tomorrow about posting it! Dave -- Dave Goodlad dgoodlad at gmail.com or dave at goodlad.ca http://david.goodlad.ca/ From aslak.hellesoy at gmail.com Fri Oct 13 03:40:18 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Fri, 13 Oct 2006 09:40:18 +0200 Subject: [rspec-devel] [ rspec-Feature Requests-6098 ] Make scaffold_resource generator In-Reply-To: References: <20061011100142.327EB5240EF2@rubyforge.org> <8d961d900610121347h75620133s9f3f63c0d455d2d3@mail.gmail.com> Message-ID: <8d961d900610130040rc6c1ad6w842f67ad8ada76a6@mail.gmail.com> On 10/13/06, David Goodlad wrote: > Hi Aslak (and Dave - can only 'reply' to one message) > > > > Should I try to get permission to post it publicly? Would it fill this need? > > > > > > > That would be great. If you get legal clearance for it, please post > > the code as an attatchment to the RFE above. > > Will do. > > I just added some basic views to the generator, but they don't > automatically add fields like the normal scaffolding: I prefer to set > that up by hand... I'll talk to my boss tomorrow about posting it! > Great! Take a look at how RSpec on Rails' existing generators are done if you haven't already. I'd very much like this new generator to reuse as much as possible from the official generator - the RSpec generator should really only differ in that it generates specs instead of tests. Cheers, Aslak > Dave > > -- > Dave Goodlad > dgoodlad at gmail.com or dave at goodlad.ca > http://david.goodlad.ca/ > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From jerry.west at ntlworld.com Fri Oct 13 11:59:16 2006 From: jerry.west at ntlworld.com (Jerry West) Date: Fri, 13 Oct 2006 16:59:16 +0100 Subject: [rspec-devel] Rpec with Locomo In-Reply-To: <5fa283580610121356x675d7f44pa96e389185c53e59@mail.gmail.com> References: <5fa283580610120427q7c0472e2ic91ea93eeabd9644@mail.gmail.com> <5fa283580610121356x675d7f44pa96e389185c53e59@mail.gmail.com> Message-ID: <452FB7D4.3060808@ntlworld.com> This message (using SQLite) may be masking other errors or exceptions - usually faulty fixtures in my case. See also http://dev.rubyonrails.org/ticket/2749 Rgds, Jerry Bolo Michelin wrote: > Nobody ? > my spec.file > require File.dirname(__FILE__) + '/../spec_helper' > module FaqSpecHelper > def validate_faq_attributes > { :question_fr => 'titre de la question', > :response_fr => 'reponse de la question'} > end > end > > context "une faq en g?n?ral" do > def setup > @faq = Faq.new > end > > specify "devras ?tre invalide sans question" do > #doit avoir une r?ponse valide > @faq.reponse_fr = 'le_titre_de_la_question' > @faq.should_not_be_valid > @faq.errors.on(:question_fr).should_equal "est necessaire" > @faq.question_fr = 'le_titre_de_la_question' > @faq.should_be_valid > end > > specify "devras ?tre invalide sans r?ponse" do > #doit avoir une question valide > @faq.question_fr = 'le_titre_de_la_question' > @faq.should_not_be_valid > @faq.errors.on(:reponse_fr).should_equal "est necessaire" > @faq.reponse_fr = 'le_titre_de_la_question' > @faq.should_be_valid > end > end > > > 2006/10/12, Bolo Michelin >: > > Hello > > I turn off transactional_fixture > self.use_transactional_fixtures = false > > But when i tested rcpec have this error > > pc-mq-dsi3:~/Documents/Coding-Dev/expay_corporate bmichelin$ spec > spec/models/faq_spec.rb > > /Applications/Locomotive2/Bundles/standardRailsSept2006.locobundle/i386/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.1.0/lib/sqlite3/errors.rb:94:in > `check': cannot rollback - no transaction is active > (SQLite3::SQLException) > > thanks > > -- > Bolo Michelin > web: http://www.independza.com > > > > > -- > Bolo Michelin > web: http://www.independza.com > ------------------------------------------------------------------------ > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From noreply at rubyforge.org Fri Oct 13 23:40:28 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 13 Oct 2006 23:40:28 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-5844 ] Stub method Message-ID: <20061014034028.D3D4B52416D7@rubyforge.org> Patches item #5844, was opened at 2006-09-22 00:50 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=5844&group_id=797 Category: None Group: None >Status: Closed Resolution: Accepted Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Brian Takita (btakita) Summary: Stub method Initial Comment: This patch allows objects to be stubbed. It also reverts the object to its unstubbed state after the spec is finished executing. For example: require File.dirname(__FILE__) + '/../lib/spec' context "A consumer of a stub" do specify "should be able to stub objects" do obj = Object.new stub(obj).method(:foobar).with {:return_value} obj.foobar.should_equal :return_value end end ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-09-27 12:59 Message: I'm reopening this since it's reverted from trunk and now lives in branches/stubs until we're happy with the API and docs are written. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-09-22 05:53 Message: Committed in revision 786 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=5844&group_id=797 From aslak.hellesoy at gmail.com Sat Oct 14 11:24:50 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sat, 14 Oct 2006 17:24:50 +0200 Subject: [rspec-devel] dogfood time? In-Reply-To: <57c63afe0610111228n1dab0b83y10a2837e62d68054@mail.gmail.com> References: <8d961d900610101827p54a27367od82480b5d6bcc63e@mail.gmail.com> <22A2E499-6587-4341-9C0F-3DF4A4E00888@daveastels.com> <57c63afe0610111228n1dab0b83y10a2837e62d68054@mail.gmail.com> Message-ID: <8d961d900610140824g6f093437x9b10f70de43e0379@mail.gmail.com> On 10/11/06, David Chelimsky wrote: > On 10/11/06, Dave Astels wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > > > On 10-Oct-06, at 10:27 PM, aslak hellesoy wrote: > > > > > A while ago I brought up the idea of making RSpec self-hosting. I.e. > > > completely ditch RSpec's own Test::Unit tests and use RSpec to verify > > > itself during the build process. > > > > > > One of the counter arguments that came up (I think it was Dave) was > > > "what if we have bugs that get masked". > > > > > > I think that at this point RSpec core is mature enough to make it > > > worth the risk. I think the risk of having masked bugs is minimal - I > > > think we'd discover it quickly if it happened. > > > > > > What do you think? Is it time to trust our own tool and eat our own > > > dogfood? > > > (We'd check in the test2spec generated translations, reformat them and > > > delete the Test::Unit tests plus test2spec) > > > > I think you're right that it's ready for that now. > > > > +1 > > +1 > > One word of caution on this. There are test/unit tests that don't get > translated in the build because they test things like the ability of > partial mocks to attach themselves to the Specification that is > current running. When running a Specification INSIDE a Specification, > the mocks attach themselves to the wrong spec. So this area will need > to be restructured such that we can translate all of the specs before > we follow through on this. > I have created branches/dogfood for this. Work done so far: * Checked in translated specs under the specs folder * Translated by hand specs that didn't translate (mock_spec.rb, context_spec.rb and a couple of others) * Deleted test2spec and all references in the doco and the Rakefile * Code coverage is now up from 95.8% to 98.3% Remaining work: * Delete the Test::Unit tests * Replace curlies with do/end (A regexp search/replace should do fine) * Indent/reformat the specs so they look nice. Does anyone know of a tool that can format badly formatted ruby code nicely? I'd like to get this back to trunk as soon as possible to avoid divergence. Any objections if I merge back before we've sorted the curlies/formatting issues? Aslak > That said, I love the idea of rspec spec'ing itself. > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From aslak.hellesoy at gmail.com Sat Oct 14 12:41:06 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sat, 14 Oct 2006 18:41:06 +0200 Subject: [rspec-devel] --colour with progress bar In-Reply-To: References: <57c63afe0610050629s60e2abd9o4da871fe1784552@mail.gmail.com> Message-ID: <8d961d900610140941u790f3aech8f63eb332994e323@mail.gmail.com> On 10/6/06, KAKUTANI Shintaro wrote: > Hi, > > At Thu, 5 Oct 2006 08:29:33 -0500, > David Chelimsky wrote: > > > > How about sticking this in a custom formatter? > > > > I was expected to see colored text on both a result summary and a progress bar > when my first running spec command with -c option. > > That's not unnatural expectation to me. > and Test::Unit with RedGreen supports that feature. > > > spec spec -f MyCustomFormatter --require my_custom_formatter.rb > > I'll try that. Thanks! > It was a small refactoring to add support for colour in the progress bar. It currently lives on the branches/dogfood branch, which will be merged to trunk soon. Aslak > > Sincerely, > -- > { :name: ["KAKUTANI", "Shintaro"], > :email: shintaro at kakutani.com, :website: http://kakutani.com/ } > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From brian.takita at gmail.com Sat Oct 14 15:03:13 2006 From: brian.takita at gmail.com (Brian Takita) Date: Sat, 14 Oct 2006 12:03:13 -0700 Subject: [rspec-devel] dogfood time? In-Reply-To: <8d961d900610140824g6f093437x9b10f70de43e0379@mail.gmail.com> References: <8d961d900610101827p54a27367od82480b5d6bcc63e@mail.gmail.com> <22A2E499-6587-4341-9C0F-3DF4A4E00888@daveastels.com> <57c63afe0610111228n1dab0b83y10a2837e62d68054@mail.gmail.com> <8d961d900610140824g6f093437x9b10f70de43e0379@mail.gmail.com> Message-ID: <1d7ddd110610141203w11d00ac3h1123224ea3a82c9c@mail.gmail.com> On 10/14/06, aslak hellesoy wrote: > > On 10/11/06, David Chelimsky wrote: > > On 10/11/06, Dave Astels wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > > > > On 10-Oct-06, at 10:27 PM, aslak hellesoy wrote: > > > > > > > A while ago I brought up the idea of making RSpec self-hosting. I.e. > > > > completely ditch RSpec's own Test::Unit tests and use RSpec to > verify > > > > itself during the build process. > > > > > > > > One of the counter arguments that came up (I think it was Dave) was > > > > "what if we have bugs that get masked". > > > > > > > > I think that at this point RSpec core is mature enough to make it > > > > worth the risk. I think the risk of having masked bugs is minimal - > I > > > > think we'd discover it quickly if it happened. > > > > > > > > What do you think? Is it time to trust our own tool and eat our own > > > > dogfood? > > > > (We'd check in the test2spec generated translations, reformat them > and > > > > delete the Test::Unit tests plus test2spec) > > > > > > I think you're right that it's ready for that now. > > > > > > +1 > > > > +1 > > > > One word of caution on this. There are test/unit tests that don't get > > translated in the build because they test things like the ability of > > partial mocks to attach themselves to the Specification that is > > current running. When running a Specification INSIDE a Specification, > > the mocks attach themselves to the wrong spec. So this area will need > > to be restructured such that we can translate all of the specs before > > we follow through on this. > > > > I have created branches/dogfood for this. Work done so far: > > * Checked in translated specs under the specs folder > * Translated by hand specs that didn't translate (mock_spec.rb, > context_spec.rb and a couple of others) > * Deleted test2spec and all references in the doco and the Rakefile > * Code coverage is now up from 95.8% to 98.3% Awesome. Remaining work: > * Delete the Test::Unit tests > * Replace curlies with do/end (A regexp search/replace should do fine) > * Indent/reformat the specs so they look nice. Was it difficult to do? Are there any rough areas? Does anyone know of a tool that can format badly formatted ruby code nicely? Eclipse RDT? Textmate? I'd like to get this back to trunk as soon as possible to avoid > divergence. Any objections if I merge back before we've sorted the > curlies/formatting issues? That sounds like a good idea. Aslak > > > That said, I love the idea of rspec spec'ing itself. > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061014/2dab65b0/attachment.html From dchelimsky at gmail.com Sat Oct 14 15:46:14 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 14 Oct 2006 15:46:14 -0400 Subject: [rspec-devel] dogfood time? In-Reply-To: <1d7ddd110610141203w11d00ac3h1123224ea3a82c9c@mail.gmail.com> References: <8d961d900610101827p54a27367od82480b5d6bcc63e@mail.gmail.com> <22A2E499-6587-4341-9C0F-3DF4A4E00888@daveastels.com> <57c63afe0610111228n1dab0b83y10a2837e62d68054@mail.gmail.com> <8d961d900610140824g6f093437x9b10f70de43e0379@mail.gmail.com> <1d7ddd110610141203w11d00ac3h1123224ea3a82c9c@mail.gmail.com> Message-ID: <57c63afe0610141246s331c59c4k5c185c9bf22c878f@mail.gmail.com> On 10/14/06, Brian Takita wrote: > On 10/14/06, aslak hellesoy wrote: > > > On 10/11/06, David Chelimsky wrote: > > > On 10/11/06, Dave Astels wrote: > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > > Hash: SHA1 > > > > > > > > > > > > On 10-Oct-06, at 10:27 PM, aslak hellesoy wrote: > > > > > > > > > A while ago I brought up the idea of making RSpec self-hosting. I.e. > > > > > completely ditch RSpec's own Test::Unit tests and use RSpec to > verify > > > > > itself during the build process. > > > > > > > > > > One of the counter arguments that came up (I think it was Dave) was > > > > > "what if we have bugs that get masked". > > > > > > > > > > I think that at this point RSpec core is mature enough to make it > > > > > worth the risk. I think the risk of having masked bugs is minimal - > I > > > > > think we'd discover it quickly if it happened. > > > > > > > > > > What do you think? Is it time to trust our own tool and eat our own > > > > > dogfood? > > > > > (We'd check in the test2spec generated translations, reformat them > and > > > > > delete the Test::Unit tests plus test2spec) > > > > > > > > I think you're right that it's ready for that now. > > > > > > > > +1 > > > > > > +1 > > > > > > One word of caution on this. There are test/unit tests that don't get > > > translated in the build because they test things like the ability of > > > partial mocks to attach themselves to the Specification that is > > > current running. When running a Specification INSIDE a Specification, > > > the mocks attach themselves to the wrong spec. So this area will need > > > to be restructured such that we can translate all of the specs before > > > we follow through on this. > > > > > > > I have created branches/dogfood for this. Work done so far: > > > > * Checked in translated specs under the specs folder > > * Translated by hand specs that didn't translate (mock_spec.rb, > > context_spec.rb and a couple of others) > > * Deleted test2spec and all references in the doco and the Rakefile > > * Code coverage is now up from 95.8% to 98.3% > > Awesome. > > > Remaining work: > > * Delete the Test::Unit tests > > * Replace curlies with do/end (A regexp search/replace should do fine) > > * Indent/reformat the specs so they look nice. > > Was it difficult to do? Are there any rough areas? > > > Does anyone know of a tool that can format badly formatted ruby code > nicely? > > > Eclipse RDT? Textmate? > > > I'd like to get this back to trunk as soon as possible to avoid > > divergence. Any objections if I merge back before we've sorted the > > curlies/formatting issues? > > That sounds like a good idea. +1 > > > Aslak > > > > > That said, I love the idea of rspec spec'ing itself. > > > _______________________________________________ > > > rspec-devel mailing list > > > rspec-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > From dchelimsky at gmail.com Sat Oct 14 15:53:22 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 14 Oct 2006 15:53:22 -0400 Subject: [rspec-devel] dogfood time? In-Reply-To: <57c63afe0610141246s331c59c4k5c185c9bf22c878f@mail.gmail.com> References: <8d961d900610101827p54a27367od82480b5d6bcc63e@mail.gmail.com> <22A2E499-6587-4341-9C0F-3DF4A4E00888@daveastels.com> <57c63afe0610111228n1dab0b83y10a2837e62d68054@mail.gmail.com> <8d961d900610140824g6f093437x9b10f70de43e0379@mail.gmail.com> <1d7ddd110610141203w11d00ac3h1123224ea3a82c9c@mail.gmail.com> <57c63afe0610141246s331c59c4k5c185c9bf22c878f@mail.gmail.com> Message-ID: <57c63afe0610141253k546992e5xbe3dce97fdfb9aab@mail.gmail.com> On 10/14/06, David Chelimsky wrote: > On 10/14/06, Brian Takita wrote: > > On 10/14/06, aslak hellesoy wrote: > > > > > On 10/11/06, David Chelimsky wrote: > > > > On 10/11/06, Dave Astels wrote: > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > > > Hash: SHA1 > > > > > > > > > > > > > > > On 10-Oct-06, at 10:27 PM, aslak hellesoy wrote: > > > > > > > > > > > A while ago I brought up the idea of making RSpec self-hosting. I.e. > > > > > > completely ditch RSpec's own Test::Unit tests and use RSpec to > > verify > > > > > > itself during the build process. > > > > > > > > > > > > One of the counter arguments that came up (I think it was Dave) was > > > > > > "what if we have bugs that get masked". > > > > > > > > > > > > I think that at this point RSpec core is mature enough to make it > > > > > > worth the risk. I think the risk of having masked bugs is minimal - > > I > > > > > > think we'd discover it quickly if it happened. > > > > > > > > > > > > What do you think? Is it time to trust our own tool and eat our own > > > > > > dogfood? > > > > > > (We'd check in the test2spec generated translations, reformat them > > and > > > > > > delete the Test::Unit tests plus test2spec) > > > > > > > > > > I think you're right that it's ready for that now. > > > > > > > > > > +1 > > > > > > > > +1 > > > > > > > > One word of caution on this. There are test/unit tests that don't get > > > > translated in the build because they test things like the ability of > > > > partial mocks to attach themselves to the Specification that is > > > > current running. When running a Specification INSIDE a Specification, > > > > the mocks attach themselves to the wrong spec. So this area will need > > > > to be restructured such that we can translate all of the specs before > > > > we follow through on this. > > > > > > > > > > I have created branches/dogfood for this. Work done so far: > > > > > > * Checked in translated specs under the specs folder > > > * Translated by hand specs that didn't translate (mock_spec.rb, > > > context_spec.rb and a couple of others) > > > * Deleted test2spec and all references in the doco and the Rakefile > > > * Code coverage is now up from 95.8% to 98.3% > > > > Awesome. > > > > > Remaining work: > > > * Delete the Test::Unit tests > > > * Replace curlies with do/end (A regexp search/replace should do fine) > > > * Indent/reformat the specs so they look nice. > > > > Was it difficult to do? Are there any rough areas? > > > > > Does anyone know of a tool that can format badly formatted ruby code > > nicely? > > > > > > Eclipse RDT? Textmate? > > > > > I'd like to get this back to trunk as soon as possible to avoid > > > divergence. Any objections if I merge back before we've sorted the > > > curlies/formatting issues? > > > > That sounds like a good idea. > > +1 One additional thought - when you merge, can you diff the trunk against the revision (on the trunk) when you created the branch? If there are any new test methods there (which there might be) they'll get lost in the shuffle if you just merge in the changes (which include deleting all of the test/unit tests). Thanks, David From aslak.hellesoy at gmail.com Sat Oct 14 15:53:36 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sat, 14 Oct 2006 21:53:36 +0200 Subject: [rspec-devel] dogfood time? In-Reply-To: <1d7ddd110610141203w11d00ac3h1123224ea3a82c9c@mail.gmail.com> References: <8d961d900610101827p54a27367od82480b5d6bcc63e@mail.gmail.com> <22A2E499-6587-4341-9C0F-3DF4A4E00888@daveastels.com> <57c63afe0610111228n1dab0b83y10a2837e62d68054@mail.gmail.com> <8d961d900610140824g6f093437x9b10f70de43e0379@mail.gmail.com> <1d7ddd110610141203w11d00ac3h1123224ea3a82c9c@mail.gmail.com> Message-ID: <8d961d900610141253x2bd879f3o97ebc76534329f0a@mail.gmail.com> On 10/14/06, Brian Takita wrote: > On 10/14/06, aslak hellesoy wrote: > > > On 10/11/06, David Chelimsky wrote: > > > On 10/11/06, Dave Astels wrote: > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > > Hash: SHA1 > > > > > > > > > > > > On 10-Oct-06, at 10:27 PM, aslak hellesoy wrote: > > > > > > > > > A while ago I brought up the idea of making RSpec self-hosting. I.e. > > > > > completely ditch RSpec's own Test::Unit tests and use RSpec to > verify > > > > > itself during the build process. > > > > > > > > > > One of the counter arguments that came up (I think it was Dave) was > > > > > "what if we have bugs that get masked". > > > > > > > > > > I think that at this point RSpec core is mature enough to make it > > > > > worth the risk. I think the risk of having masked bugs is minimal - > I > > > > > think we'd discover it quickly if it happened. > > > > > > > > > > What do you think? Is it time to trust our own tool and eat our own > > > > > dogfood? > > > > > (We'd check in the test2spec generated translations, reformat them > and > > > > > delete the Test::Unit tests plus test2spec) > > > > > > > > I think you're right that it's ready for that now. > > > > > > > > +1 > > > > > > +1 > > > > > > One word of caution on this. There are test/unit tests that don't get > > > translated in the build because they test things like the ability of > > > partial mocks to attach themselves to the Specification that is > > > current running. When running a Specification INSIDE a Specification, > > > the mocks attach themselves to the wrong spec. So this area will need > > > to be restructured such that we can translate all of the specs before > > > we follow through on this. > > > > > > > I have created branches/dogfood for this. Work done so far: > > > > * Checked in translated specs under the specs folder > > * Translated by hand specs that didn't translate (mock_spec.rb, > > context_spec.rb and a couple of others) > > * Deleted test2spec and all references in the doco and the Rakefile > > * Code coverage is now up from 95.8% to 98.3% > > Awesome. > > > Remaining work: > > * Delete the Test::Unit tests > > * Replace curlies with do/end (A regexp search/replace should do fine) > > * Indent/reformat the specs so they look nice. > > Was it difficult to do? Are there any rough areas? > It was surprisingly easy and fun. Here is what I did: 1) I tweaked the test2spec setting a little so the generated specs were written to where I wanted to check them in. 2) I set up a spec task to run the translated specs - *with* rcov. 3) I ran rake spec. All the specs passed (no surprise - test2spec translated specs have been running as part of our pre_commit build for months) 4) Looked at the rcov report and noticed there was a bunch of red (non-covered code) that was otherwise covered OK by Test::Unit. 5) Opened a file that had poorer coverage with RSpec than with Test::Unit and put a raise "FIXME" in some of the red code. 6) Ran rake test to see what test would fail (rake spec would still pass) 7) Verified that the failing test had indeed not been translated. 8) Translated it manually. 9) Removed the temporary raise "FIXME" 10) Went back to 3 until coverage was good again (it actually ended up being better since I also yanked the test2spec code) This whole effort had been extremely hard had it not been for test2spec and rcov. A last heroic effort for test2spec which has now been put to rest. > > Does anyone know of a tool that can format badly formatted ruby code > nicely? > > > Eclipse RDT? Textmate? > I don't think they can do it. If someone knows how to, please let me know the keyboard shortcuts or menu options. > > I'd like to get this back to trunk as soon as possible to avoid > > divergence. Any objections if I merge back before we've sorted the > > curlies/formatting issues? > I'm actually done with the curlies and am now formatting by hand. It's not that bad. I'll merge to trunk tomorrow unless someone says no. > That sounds like a good idea. > > > Aslak > > > > > That said, I love the idea of rspec spec'ing itself. > > > _______________________________________________ > > > rspec-devel mailing list > > > rspec-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > From noreply at rubyforge.org Sat Oct 14 09:19:19 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 14 Oct 2006 09:19:19 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-4690 ] Ordering of mock calls doesn't work in block mode Message-ID: <20061014131919.DEEE45241172@rubyforge.org> Bugs item #4690, was opened at 2006-06-06 19:31 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=4690&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Aslak Hellesoy (aslak_hellesoy) Assigned to: Nobody (None) Summary: Ordering of mock calls doesn't work in block mode Initial Comment: Two failing (and disabled) tests have been added to mock_ordering_test.rb to demonstrate this. ---------------------------------------------------------------------- >Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-14 09:19 Message: Moving the tests here: def FIXME_test_two_in_order_calls_with_block @mock.should_receive(:doit).ordered do |a, b| a.should_equal "a1" a.should_equal "b1" end @mock.should_receive(:doit).ordered do |a, b| a.should_equal "a2" a.should_equal "b2" end @mock.doit "a1", "b1" @mock.doit "b1", "b2" @mock.__verify end def FIXME_test_two_out_of_order_calls_with_block @mock.should_receive(:doit).ordered do |a, b| a.should_equal "a1" a.should_equal "b1" end @mock.should_receive(:doit).ordered do |a, b| a.should_equal "a2" a.should_equal "b2" end @mock.doit "b1", "b2" @mock.doit "a1", "b1" @mock.__verify end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=4690&group_id=797 From dchelimsky at gmail.com Sat Oct 14 15:57:28 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 14 Oct 2006 15:57:28 -0400 Subject: [rspec-devel] dogfood time? In-Reply-To: <8d961d900610141253x2bd879f3o97ebc76534329f0a@mail.gmail.com> References: <8d961d900610101827p54a27367od82480b5d6bcc63e@mail.gmail.com> <22A2E499-6587-4341-9C0F-3DF4A4E00888@daveastels.com> <57c63afe0610111228n1dab0b83y10a2837e62d68054@mail.gmail.com> <8d961d900610140824g6f093437x9b10f70de43e0379@mail.gmail.com> <1d7ddd110610141203w11d00ac3h1123224ea3a82c9c@mail.gmail.com> <8d961d900610141253x2bd879f3o97ebc76534329f0a@mail.gmail.com> Message-ID: <57c63afe0610141257y6ca6fb5bmd8985516a5dd3d6b@mail.gmail.com> On 10/14/06, aslak hellesoy wrote: > On 10/14/06, Brian Takita wrote: > > On 10/14/06, aslak hellesoy wrote: > > > > > On 10/11/06, David Chelimsky wrote: > > > > On 10/11/06, Dave Astels wrote: > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > > > Hash: SHA1 > > > > > > > > > > > > > > > On 10-Oct-06, at 10:27 PM, aslak hellesoy wrote: > > > > > > > > > > > A while ago I brought up the idea of making RSpec self-hosting. I.e. > > > > > > completely ditch RSpec's own Test::Unit tests and use RSpec to > > verify > > > > > > itself during the build process. > > > > > > > > > > > > One of the counter arguments that came up (I think it was Dave) was > > > > > > "what if we have bugs that get masked". > > > > > > > > > > > > I think that at this point RSpec core is mature enough to make it > > > > > > worth the risk. I think the risk of having masked bugs is minimal - > > I > > > > > > think we'd discover it quickly if it happened. > > > > > > > > > > > > What do you think? Is it time to trust our own tool and eat our own > > > > > > dogfood? > > > > > > (We'd check in the test2spec generated translations, reformat them > > and > > > > > > delete the Test::Unit tests plus test2spec) > > > > > > > > > > I think you're right that it's ready for that now. > > > > > > > > > > +1 > > > > > > > > +1 > > > > > > > > One word of caution on this. There are test/unit tests that don't get > > > > translated in the build because they test things like the ability of > > > > partial mocks to attach themselves to the Specification that is > > > > current running. When running a Specification INSIDE a Specification, > > > > the mocks attach themselves to the wrong spec. So this area will need > > > > to be restructured such that we can translate all of the specs before > > > > we follow through on this. > > > > > > > > > > I have created branches/dogfood for this. Work done so far: > > > > > > * Checked in translated specs under the specs folder > > > * Translated by hand specs that didn't translate (mock_spec.rb, > > > context_spec.rb and a couple of others) > > > * Deleted test2spec and all references in the doco and the Rakefile > > > * Code coverage is now up from 95.8% to 98.3% > > > > Awesome. > > > > > Remaining work: > > > * Delete the Test::Unit tests > > > * Replace curlies with do/end (A regexp search/replace should do fine) > > > * Indent/reformat the specs so they look nice. > > > > Was it difficult to do? Are there any rough areas? > > > > It was surprisingly easy and fun. Here is what I did: > > 1) I tweaked the test2spec setting a little so the generated specs > were written to where I wanted to check them in. > 2) I set up a spec task to run the translated specs - *with* rcov. > 3) I ran rake spec. All the specs passed (no surprise - test2spec > translated specs have been running as part of our pre_commit build for > months) > 4) Looked at the rcov report and noticed there was a bunch of red > (non-covered code) that was otherwise covered OK by Test::Unit. > 5) Opened a file that had poorer coverage with RSpec than with > Test::Unit and put a raise "FIXME" in some of the red code. > 6) Ran rake test to see what test would fail (rake spec would still pass) > 7) Verified that the failing test had indeed not been translated. > 8) Translated it manually. > 9) Removed the temporary raise "FIXME" > 10) Went back to 3 until coverage was good again (it actually ended up > being better since I also yanked the test2spec code) > > This whole effort had been extremely hard had it not been for > test2spec and rcov. A last heroic effort for test2spec which has now > been put to rest. > > > > Does anyone know of a tool that can format badly formatted ruby code > > nicely? > > > > > > Eclipse RDT? Textmate? > > > > I don't think they can do it. If someone knows how to, please let me > know the keyboard shortcuts or menu options. > > > > I'd like to get this back to trunk as soon as possible to avoid > > > divergence. Any objections if I merge back before we've sorted the > > > curlies/formatting issues? > > > > I'm actually done with the curlies and am now formatting by hand. It's > not that bad. > I'll merge to trunk tomorrow unless someone says no. One other thing - not necessary before merging - I notice many spec files look like this: module Spec module Mocks context "xyz" do ... end end end I'd like to kill the module declarations. Great work on this Aslak. This is a really exciting step for us. Thanks, David > > > That sounds like a good idea. > > > > > Aslak > > > > > > > That said, I love the idea of rspec spec'ing itself. > > > > _______________________________________________ > > > > rspec-devel mailing list > > > > rspec-devel at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > _______________________________________________ > > > rspec-devel mailing list > > > rspec-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From aslak.hellesoy at gmail.com Sat Oct 14 16:17:13 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sat, 14 Oct 2006 22:17:13 +0200 Subject: [rspec-devel] dogfood time? In-Reply-To: <57c63afe0610141253k546992e5xbe3dce97fdfb9aab@mail.gmail.com> References: <8d961d900610101827p54a27367od82480b5d6bcc63e@mail.gmail.com> <22A2E499-6587-4341-9C0F-3DF4A4E00888@daveastels.com> <57c63afe0610111228n1dab0b83y10a2837e62d68054@mail.gmail.com> <8d961d900610140824g6f093437x9b10f70de43e0379@mail.gmail.com> <1d7ddd110610141203w11d00ac3h1123224ea3a82c9c@mail.gmail.com> <57c63afe0610141246s331c59c4k5c185c9bf22c878f@mail.gmail.com> <57c63afe0610141253k546992e5xbe3dce97fdfb9aab@mail.gmail.com> Message-ID: <8d961d900610141317ifd08970wcd237fc5945750ca@mail.gmail.com> On 10/14/06, David Chelimsky wrote: > On 10/14/06, David Chelimsky wrote: > > On 10/14/06, Brian Takita wrote: > > > On 10/14/06, aslak hellesoy wrote: > > > > > > > On 10/11/06, David Chelimsky wrote: > > > > > On 10/11/06, Dave Astels wrote: > > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > > > > Hash: SHA1 > > > > > > > > > > > > > > > > > > On 10-Oct-06, at 10:27 PM, aslak hellesoy wrote: > > > > > > > > > > > > > A while ago I brought up the idea of making RSpec self-hosting. I.e. > > > > > > > completely ditch RSpec's own Test::Unit tests and use RSpec to > > > verify > > > > > > > itself during the build process. > > > > > > > > > > > > > > One of the counter arguments that came up (I think it was Dave) was > > > > > > > "what if we have bugs that get masked". > > > > > > > > > > > > > > I think that at this point RSpec core is mature enough to make it > > > > > > > worth the risk. I think the risk of having masked bugs is minimal - > > > I > > > > > > > think we'd discover it quickly if it happened. > > > > > > > > > > > > > > What do you think? Is it time to trust our own tool and eat our own > > > > > > > dogfood? > > > > > > > (We'd check in the test2spec generated translations, reformat them > > > and > > > > > > > delete the Test::Unit tests plus test2spec) > > > > > > > > > > > > I think you're right that it's ready for that now. > > > > > > > > > > > > +1 > > > > > > > > > > +1 > > > > > > > > > > One word of caution on this. There are test/unit tests that don't get > > > > > translated in the build because they test things like the ability of > > > > > partial mocks to attach themselves to the Specification that is > > > > > current running. When running a Specification INSIDE a Specification, > > > > > the mocks attach themselves to the wrong spec. So this area will need > > > > > to be restructured such that we can translate all of the specs before > > > > > we follow through on this. > > > > > > > > > > > > > I have created branches/dogfood for this. Work done so far: > > > > > > > > * Checked in translated specs under the specs folder > > > > * Translated by hand specs that didn't translate (mock_spec.rb, > > > > context_spec.rb and a couple of others) > > > > * Deleted test2spec and all references in the doco and the Rakefile > > > > * Code coverage is now up from 95.8% to 98.3% > > > > > > Awesome. > > > > > > > Remaining work: > > > > * Delete the Test::Unit tests > > > > * Replace curlies with do/end (A regexp search/replace should do fine) > > > > * Indent/reformat the specs so they look nice. > > > > > > Was it difficult to do? Are there any rough areas? > > > > > > > Does anyone know of a tool that can format badly formatted ruby code > > > nicely? > > > > > > > > > Eclipse RDT? Textmate? > > > > > > > I'd like to get this back to trunk as soon as possible to avoid > > > > divergence. Any objections if I merge back before we've sorted the > > > > curlies/formatting issues? > > > > > > That sounds like a good idea. > > > > +1 > > One additional thought - when you merge, can you diff the trunk > against the revision (on the trunk) when you created the branch? If > there are any new test methods there (which there might be) they'll > get lost in the shuffle if you just merge in the changes (which > include deleting all of the test/unit tests). > Will do. There is nothing new on the trunk from when I created the branch earlier today. So if everyone can stay out of trunk for a few hours it will be all smooth. > Thanks, > David > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From aslak.hellesoy at gmail.com Sat Oct 14 16:22:44 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sat, 14 Oct 2006 22:22:44 +0200 Subject: [rspec-devel] dogfood time? In-Reply-To: <57c63afe0610141257y6ca6fb5bmd8985516a5dd3d6b@mail.gmail.com> References: <8d961d900610101827p54a27367od82480b5d6bcc63e@mail.gmail.com> <22A2E499-6587-4341-9C0F-3DF4A4E00888@daveastels.com> <57c63afe0610111228n1dab0b83y10a2837e62d68054@mail.gmail.com> <8d961d900610140824g6f093437x9b10f70de43e0379@mail.gmail.com> <1d7ddd110610141203w11d00ac3h1123224ea3a82c9c@mail.gmail.com> <8d961d900610141253x2bd879f3o97ebc76534329f0a@mail.gmail.com> <57c63afe0610141257y6ca6fb5bmd8985516a5dd3d6b@mail.gmail.com> Message-ID: <8d961d900610141322j51cce261pd9706c3c39e54e36@mail.gmail.com> On 10/14/06, David Chelimsky wrote: > On 10/14/06, aslak hellesoy wrote: > > On 10/14/06, Brian Takita wrote: > > > On 10/14/06, aslak hellesoy wrote: > > > > > > > On 10/11/06, David Chelimsky wrote: > > > > > On 10/11/06, Dave Astels wrote: > > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > > > > Hash: SHA1 > > > > > > > > > > > > > > > > > > On 10-Oct-06, at 10:27 PM, aslak hellesoy wrote: > > > > > > > > > > > > > A while ago I brought up the idea of making RSpec self-hosting. I.e. > > > > > > > completely ditch RSpec's own Test::Unit tests and use RSpec to > > > verify > > > > > > > itself during the build process. > > > > > > > > > > > > > > One of the counter arguments that came up (I think it was Dave) was > > > > > > > "what if we have bugs that get masked". > > > > > > > > > > > > > > I think that at this point RSpec core is mature enough to make it > > > > > > > worth the risk. I think the risk of having masked bugs is minimal - > > > I > > > > > > > think we'd discover it quickly if it happened. > > > > > > > > > > > > > > What do you think? Is it time to trust our own tool and eat our own > > > > > > > dogfood? > > > > > > > (We'd check in the test2spec generated translations, reformat them > > > and > > > > > > > delete the Test::Unit tests plus test2spec) > > > > > > > > > > > > I think you're right that it's ready for that now. > > > > > > > > > > > > +1 > > > > > > > > > > +1 > > > > > > > > > > One word of caution on this. There are test/unit tests that don't get > > > > > translated in the build because they test things like the ability of > > > > > partial mocks to attach themselves to the Specification that is > > > > > current running. When running a Specification INSIDE a Specification, > > > > > the mocks attach themselves to the wrong spec. So this area will need > > > > > to be restructured such that we can translate all of the specs before > > > > > we follow through on this. > > > > > > > > > > > > > I have created branches/dogfood for this. Work done so far: > > > > > > > > * Checked in translated specs under the specs folder > > > > * Translated by hand specs that didn't translate (mock_spec.rb, > > > > context_spec.rb and a couple of others) > > > > * Deleted test2spec and all references in the doco and the Rakefile > > > > * Code coverage is now up from 95.8% to 98.3% > > > > > > Awesome. > > > > > > > Remaining work: > > > > * Delete the Test::Unit tests > > > > * Replace curlies with do/end (A regexp search/replace should do fine) > > > > * Indent/reformat the specs so they look nice. > > > > > > Was it difficult to do? Are there any rough areas? > > > > > > > It was surprisingly easy and fun. Here is what I did: > > > > 1) I tweaked the test2spec setting a little so the generated specs > > were written to where I wanted to check them in. > > 2) I set up a spec task to run the translated specs - *with* rcov. > > 3) I ran rake spec. All the specs passed (no surprise - test2spec > > translated specs have been running as part of our pre_commit build for > > months) > > 4) Looked at the rcov report and noticed there was a bunch of red > > (non-covered code) that was otherwise covered OK by Test::Unit. > > 5) Opened a file that had poorer coverage with RSpec than with > > Test::Unit and put a raise "FIXME" in some of the red code. > > 6) Ran rake test to see what test would fail (rake spec would still pass) > > 7) Verified that the failing test had indeed not been translated. > > 8) Translated it manually. > > 9) Removed the temporary raise "FIXME" > > 10) Went back to 3 until coverage was good again (it actually ended up > > being better since I also yanked the test2spec code) > > > > This whole effort had been extremely hard had it not been for > > test2spec and rcov. A last heroic effort for test2spec which has now > > been put to rest. > > > > > > Does anyone know of a tool that can format badly formatted ruby code > > > nicely? > > > > > > > > > Eclipse RDT? Textmate? > > > > > > > I don't think they can do it. If someone knows how to, please let me > > know the keyboard shortcuts or menu options. > > > > > > I'd like to get this back to trunk as soon as possible to avoid > > > > divergence. Any objections if I merge back before we've sorted the > > > > curlies/formatting issues? > > > > > > > I'm actually done with the curlies and am now formatting by hand. It's > > not that bad. > > I'll merge to trunk tomorrow unless someone says no. > > One other thing - not necessary before merging - I notice many spec > files look like this: > > module Spec > module Mocks > context "xyz" do > ... > end > end > end > > I'd like to kill the module declarations. > Me too. We can use include for that. Thanks Brian! :-D context "xyz" do include Spec::Mocks ... end > Great work on this Aslak. This is a really exciting step for us. > Thanks! I'm pretty psyched about it. > Thanks, > David > > > > > > That sounds like a good idea. > > > > > > > Aslak > > > > > > > > > That said, I love the idea of rspec spec'ing itself. > > > > > _______________________________________________ > > > > > rspec-devel mailing list > > > > > rspec-devel at rubyforge.org > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > _______________________________________________ > > > > rspec-devel mailing list > > > > rspec-devel at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > _______________________________________________ > > > rspec-devel mailing list > > > rspec-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From aslak.hellesoy at gmail.com Sat Oct 14 16:28:29 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sat, 14 Oct 2006 22:28:29 +0200 Subject: [rspec-devel] dogfood time? In-Reply-To: <8d961d900610141322j51cce261pd9706c3c39e54e36@mail.gmail.com> References: <8d961d900610101827p54a27367od82480b5d6bcc63e@mail.gmail.com> <22A2E499-6587-4341-9C0F-3DF4A4E00888@daveastels.com> <57c63afe0610111228n1dab0b83y10a2837e62d68054@mail.gmail.com> <8d961d900610140824g6f093437x9b10f70de43e0379@mail.gmail.com> <1d7ddd110610141203w11d00ac3h1123224ea3a82c9c@mail.gmail.com> <8d961d900610141253x2bd879f3o97ebc76534329f0a@mail.gmail.com> <57c63afe0610141257y6ca6fb5bmd8985516a5dd3d6b@mail.gmail.com> <8d961d900610141322j51cce261pd9706c3c39e54e36@mail.gmail.com> Message-ID: <8d961d900610141328g7a751691yf9d50ec77123016a@mail.gmail.com> On 10/14/06, aslak hellesoy wrote: > On 10/14/06, David Chelimsky wrote: > > On 10/14/06, aslak hellesoy wrote: > > > On 10/14/06, Brian Takita wrote: > > > > On 10/14/06, aslak hellesoy wrote: > > > > > > > > > On 10/11/06, David Chelimsky wrote: > > > > > > On 10/11/06, Dave Astels wrote: > > > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > > > > > Hash: SHA1 > > > > > > > > > > > > > > > > > > > > > On 10-Oct-06, at 10:27 PM, aslak hellesoy wrote: > > > > > > > > > > > > > > > A while ago I brought up the idea of making RSpec self-hosting. I.e. > > > > > > > > completely ditch RSpec's own Test::Unit tests and use RSpec to > > > > verify > > > > > > > > itself during the build process. > > > > > > > > > > > > > > > > One of the counter arguments that came up (I think it was Dave) was > > > > > > > > "what if we have bugs that get masked". > > > > > > > > > > > > > > > > I think that at this point RSpec core is mature enough to make it > > > > > > > > worth the risk. I think the risk of having masked bugs is minimal - > > > > I > > > > > > > > think we'd discover it quickly if it happened. > > > > > > > > > > > > > > > > What do you think? Is it time to trust our own tool and eat our own > > > > > > > > dogfood? > > > > > > > > (We'd check in the test2spec generated translations, reformat them > > > > and > > > > > > > > delete the Test::Unit tests plus test2spec) > > > > > > > > > > > > > > I think you're right that it's ready for that now. > > > > > > > > > > > > > > +1 > > > > > > > > > > > > +1 > > > > > > > > > > > > One word of caution on this. There are test/unit tests that don't get > > > > > > translated in the build because they test things like the ability of > > > > > > partial mocks to attach themselves to the Specification that is > > > > > > current running. When running a Specification INSIDE a Specification, > > > > > > the mocks attach themselves to the wrong spec. So this area will need > > > > > > to be restructured such that we can translate all of the specs before > > > > > > we follow through on this. > > > > > > > > > > > > > > > > I have created branches/dogfood for this. Work done so far: > > > > > > > > > > * Checked in translated specs under the specs folder > > > > > * Translated by hand specs that didn't translate (mock_spec.rb, > > > > > context_spec.rb and a couple of others) > > > > > * Deleted test2spec and all references in the doco and the Rakefile > > > > > * Code coverage is now up from 95.8% to 98.3% > > > > > > > > Awesome. > > > > > > > > > Remaining work: > > > > > * Delete the Test::Unit tests > > > > > * Replace curlies with do/end (A regexp search/replace should do fine) > > > > > * Indent/reformat the specs so they look nice. > > > > > > > > Was it difficult to do? Are there any rough areas? > > > > > > > > > > It was surprisingly easy and fun. Here is what I did: > > > > > > 1) I tweaked the test2spec setting a little so the generated specs > > > were written to where I wanted to check them in. > > > 2) I set up a spec task to run the translated specs - *with* rcov. > > > 3) I ran rake spec. All the specs passed (no surprise - test2spec > > > translated specs have been running as part of our pre_commit build for > > > months) > > > 4) Looked at the rcov report and noticed there was a bunch of red > > > (non-covered code) that was otherwise covered OK by Test::Unit. > > > 5) Opened a file that had poorer coverage with RSpec than with > > > Test::Unit and put a raise "FIXME" in some of the red code. > > > 6) Ran rake test to see what test would fail (rake spec would still pass) > > > 7) Verified that the failing test had indeed not been translated. > > > 8) Translated it manually. > > > 9) Removed the temporary raise "FIXME" > > > 10) Went back to 3 until coverage was good again (it actually ended up > > > being better since I also yanked the test2spec code) > > > > > > This whole effort had been extremely hard had it not been for > > > test2spec and rcov. A last heroic effort for test2spec which has now > > > been put to rest. > > > > > > > > Does anyone know of a tool that can format badly formatted ruby code > > > > nicely? > > > > > > > > > > > > Eclipse RDT? Textmate? > > > > > > > > > > I don't think they can do it. If someone knows how to, please let me > > > know the keyboard shortcuts or menu options. > > > > > > > > I'd like to get this back to trunk as soon as possible to avoid > > > > > divergence. Any objections if I merge back before we've sorted the > > > > > curlies/formatting issues? > > > > > > > > > > I'm actually done with the curlies and am now formatting by hand. It's > > > not that bad. > > > I'll merge to trunk tomorrow unless someone says no. > > > > One other thing - not necessary before merging - I notice many spec > > files look like this: > > > > module Spec > > module Mocks > > context "xyz" do > > ... > > end > > end > > end > > > > I'd like to kill the module declarations. > > > > Me too. We can use include for that. Thanks Brian! :-D > > context "xyz" do > include Spec::Mocks > ... > end I take that back. It's not working. For now we'd have to use fully qualified class names when referring to classes. (The purpose of having specs in modules is to avoid fully-qualified class names). Any suggestions about how to deal with this? > > > Great work on this Aslak. This is a really exciting step for us. > > > > Thanks! I'm pretty psyched about it. > > > Thanks, > > David > > > > > > > > > That sounds like a good idea. > > > > > > > > > Aslak > > > > > > > > > > > That said, I love the idea of rspec spec'ing itself. > > > > > > _______________________________________________ > > > > > > rspec-devel mailing list > > > > > > rspec-devel at rubyforge.org > > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > _______________________________________________ > > > > > rspec-devel mailing list > > > > > rspec-devel at rubyforge.org > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > > > > > _______________________________________________ > > > > rspec-devel mailing list > > > > rspec-devel at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > _______________________________________________ > > > rspec-devel mailing list > > > rspec-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > From aslak.hellesoy at gmail.com Sat Oct 14 16:56:38 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sat, 14 Oct 2006 22:56:38 +0200 Subject: [rspec-devel] RSpec is verifying itself - no more Test::Unit Message-ID: <8d961d900610141356k496e5086p2d7b8d1ee0035bca@mail.gmail.com> I've just merged branches/dogfood to trunk. RSpec now verifies itself. Test::Unit - thanks for your help on the way. But we have to move on. This is a big step for RSpec. I think that using RSpec on itself will reveal new perspectives and ideas that can help us make it even better. You'll see that most of the specs have somewhat ugly formatting. I managed to get rid of the curlies, but indentation is still off and there are some other ugly leftovers. Personally I'm OK with this. I don't feel a need to go and format everything right now. I think it can be done little by little - as we revisit specs. WDYT? From dchelimsky at gmail.com Sat Oct 14 17:14:22 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 14 Oct 2006 17:14:22 -0400 Subject: [rspec-devel] RSpec is verifying itself - no more Test::Unit In-Reply-To: <8d961d900610141356k496e5086p2d7b8d1ee0035bca@mail.gmail.com> References: <8d961d900610141356k496e5086p2d7b8d1ee0035bca@mail.gmail.com> Message-ID: <57c63afe0610141414w66936505k3c9df6951ffc8ffd@mail.gmail.com> On 10/14/06, aslak hellesoy wrote: > I've just merged branches/dogfood to trunk. RSpec now verifies itself. > Test::Unit - thanks for your help on the way. But we have to move on. > > This is a big step for RSpec. I think that using RSpec on itself will > reveal new perspectives and ideas that can help us make it even > better. > > You'll see that most of the specs have somewhat ugly formatting. I > managed to get rid of the curlies, but indentation is still off and > there are some other ugly leftovers. > > Personally I'm OK with this. I don't feel a need to go and format > everything right now. I think it can be done little by little - as we > revisit specs. > > WDYT? I don't think there's urgency, but I'd like to see this happen before the next major (0.7) release. > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From david at davelee.com.au Sun Oct 15 03:30:30 2006 From: david at davelee.com.au (David Lee) Date: Sun, 15 Oct 2006 17:30:30 +1000 Subject: [rspec-devel] Test2Spec's usefulness Message-ID: Hi all, Just thought I'd pipe in as I noticed you're decommissioning test2spec. I don't doubt that it's a maintenance headache, and I couldn't get it to work for me (converting my previous Rails tests to specs). However, it would have been really helpful for me, and would make RSpec a viable option for a (large?) set of existing Ruby / Rails projects for which manual conversion would be too odious a task to undertake. I'm not really doing anything useful here, just flagging that I think it is / would be a useful tool to have. Maybe it should wait though until RSpec itself has settled down a little ... Alternatively, a few Rake tasks to help people manage using both Test::Unit & RSpec in parallel on Rails projects might be a useful addition to the rails plugin, with minimal maintenance burden. cheers, David From aslak.hellesoy at gmail.com Sun Oct 15 07:35:56 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sun, 15 Oct 2006 13:35:56 +0200 Subject: [rspec-devel] Test2Spec's usefulness In-Reply-To: References: Message-ID: <8d961d900610150435g5c7b5d38g2841c5d5dcbed322@mail.gmail.com> On 10/15/06, David Lee wrote: > Hi all, > > Just thought I'd pipe in as I noticed you're decommissioning test2spec. > > I don't doubt that it's a maintenance headache, and I couldn't get it > to work for me (converting my previous Rails tests to specs). > It's been happily translating 90-95% of RSpec's unit tests. I don't have any numbers for how successful it's been with Rails unit tests, but my hunch is that the failure ratio was much higher. > However, it would have been really helpful for me, and would make > RSpec a viable option for a (large?) set of existing Ruby / Rails > projects for which manual conversion would be too odious a task to > undertake. > You can still use test2spec by installing RSpec 0.6.4. The thing to bear in mind is that you need ParseTree 0.4.1 - it will not work with later versions. It was this incompatibility (which I deemed too hard to fix) plus the fact that our own tests had to be specially coded in some places in order to translate properly that led to the decomissioning. > I'm not really doing anything useful here, just flagging that I think > it is / would be a useful tool to have. Maybe it should wait though > until RSpec itself has settled down a little ... > > Alternatively, a few Rake tasks to help people manage using both > Test::Unit & RSpec in parallel on Rails projects might be a useful > addition to the rails plugin, with minimal maintenance burden. > You can already do that. Just install RSpec on Rails and define a task: task :test_and_spec => :test, :spec You should tweak your spec_helper.rb so that it points to fixtures under test/fixtures rather than the default, which is spec/fixtures. Please continue posting any problems you have with test2spec - we'll help you troubleshoot it. HTH, Aslak > cheers, > David > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From david at davelee.com.au Sun Oct 15 09:11:57 2006 From: david at davelee.com.au (David Lee) Date: Sun, 15 Oct 2006 23:11:57 +1000 Subject: [rspec-devel] Test2Spec's usefulness In-Reply-To: <8d961d900610150435g5c7b5d38g2841c5d5dcbed322@mail.gmail.com> References: <8d961d900610150435g5c7b5d38g2841c5d5dcbed322@mail.gmail.com> Message-ID: <8B1EC536-81F6-4846-AA79-F4A69250A3E4@davelee.com.au> Hi Aslak, I had Parsetree 1.5 installed; probably that was my blocker issue. Thanks. Maybe what's really needed here is a documentation update: the version dependency is not mentioned on http://rspec.rubyforge.org/ tools/test2spec.html ; i followed the docs there and just got a 'could not convert' or similar error for each file attempted. Also, if test2spec will require RSpec 0.6.4 that should probably be noted on the docs site. I have set up my own rake tasks already, thanks. Thanks, David On 15/10/2006, at 9:35 PM, aslak hellesoy wrote: > On 10/15/06, David Lee wrote: >> Hi all, >> >> Just thought I'd pipe in as I noticed you're decommissioning >> test2spec. >> >> I don't doubt that it's a maintenance headache, and I couldn't get it >> to work for me (converting my previous Rails tests to specs). >> > > It's been happily translating 90-95% of RSpec's unit tests. > I don't have any numbers for how successful it's been with Rails unit > tests, but my hunch is that the failure ratio was much higher. > >> However, it would have been really helpful for me, and would make >> RSpec a viable option for a (large?) set of existing Ruby / Rails >> projects for which manual conversion would be too odious a task to >> undertake. >> > > You can still use test2spec by installing RSpec 0.6.4. The thing to > bear in mind is that you need ParseTree 0.4.1 - it will not work with > later versions. > > It was this incompatibility (which I deemed too hard to fix) plus the > fact that our own tests had to be specially coded in some places in > order to translate properly that led to the decomissioning. > >> I'm not really doing anything useful here, just flagging that I think >> it is / would be a useful tool to have. Maybe it should wait though >> until RSpec itself has settled down a little ... >> >> Alternatively, a few Rake tasks to help people manage using both >> Test::Unit & RSpec in parallel on Rails projects might be a useful >> addition to the rails plugin, with minimal maintenance burden. >> > > You can already do that. Just install RSpec on Rails and define a > task: > > task :test_and_spec => :test, :spec > > You should tweak your spec_helper.rb so that it points to fixtures > under test/fixtures rather than the default, which is spec/fixtures. > > Please continue posting any problems you have with test2spec - we'll > help you troubleshoot it. > > HTH, > Aslak > >> cheers, >> David >> >> >> _______________________________________________ >> rspec-devel mailing list >> rspec-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-devel >> > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From aslak.hellesoy at gmail.com Sun Oct 15 09:20:47 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sun, 15 Oct 2006 15:20:47 +0200 Subject: [rspec-devel] Test2Spec's usefulness In-Reply-To: <8B1EC536-81F6-4846-AA79-F4A69250A3E4@davelee.com.au> References: <8d961d900610150435g5c7b5d38g2841c5d5dcbed322@mail.gmail.com> <8B1EC536-81F6-4846-AA79-F4A69250A3E4@davelee.com.au> Message-ID: <8d961d900610150620u6adbfd9dte84eac9c02706b5d@mail.gmail.com> On 10/15/06, David Lee wrote: > Hi Aslak, > > I had Parsetree 1.5 installed; probably that was my blocker issue. > Thanks. > > Maybe what's really needed here is a documentation update: the > version dependency is not mentioned on http://rspec.rubyforge.org/ > tools/test2spec.html ; i followed the docs there and just got a > 'could not convert' or similar error for each file attempted. > > Also, if test2spec will require RSpec 0.6.4 that should probably be > noted on the docs site. > When I removed test2spec from svn I also removed the documentation for it (the website is in svn as well). Unless I bring the doco back, the test2spec doco will be gone online after the next release of RSpec. Maybe we should resurrect the pages and add a big warning that it's a discontinued tool that's only available in previous releases. WDYT? Aslak > I have set up my own rake tasks already, thanks. > > Thanks, > David > > > On 15/10/2006, at 9:35 PM, aslak hellesoy wrote: > > > On 10/15/06, David Lee wrote: > >> Hi all, > >> > >> Just thought I'd pipe in as I noticed you're decommissioning > >> test2spec. > >> > >> I don't doubt that it's a maintenance headache, and I couldn't get it > >> to work for me (converting my previous Rails tests to specs). > >> > > > > It's been happily translating 90-95% of RSpec's unit tests. > > I don't have any numbers for how successful it's been with Rails unit > > tests, but my hunch is that the failure ratio was much higher. > > > >> However, it would have been really helpful for me, and would make > >> RSpec a viable option for a (large?) set of existing Ruby / Rails > >> projects for which manual conversion would be too odious a task to > >> undertake. > >> > > > > You can still use test2spec by installing RSpec 0.6.4. The thing to > > bear in mind is that you need ParseTree 0.4.1 - it will not work with > > later versions. > > > > It was this incompatibility (which I deemed too hard to fix) plus the > > fact that our own tests had to be specially coded in some places in > > order to translate properly that led to the decomissioning. > > > >> I'm not really doing anything useful here, just flagging that I think > >> it is / would be a useful tool to have. Maybe it should wait though > >> until RSpec itself has settled down a little ... > >> > >> Alternatively, a few Rake tasks to help people manage using both > >> Test::Unit & RSpec in parallel on Rails projects might be a useful > >> addition to the rails plugin, with minimal maintenance burden. > >> > > > > You can already do that. Just install RSpec on Rails and define a > > task: > > > > task :test_and_spec => :test, :spec > > > > You should tweak your spec_helper.rb so that it points to fixtures > > under test/fixtures rather than the default, which is spec/fixtures. > > > > Please continue posting any problems you have with test2spec - we'll > > help you troubleshoot it. > > > > HTH, > > Aslak > > > >> cheers, > >> David > >> > >> > >> _______________________________________________ > >> rspec-devel mailing list > >> rspec-devel at rubyforge.org > >> http://rubyforge.org/mailman/listinfo/rspec-devel > >> > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dastels at daveastels.com Sun Oct 15 15:47:48 2006 From: dastels at daveastels.com (Dave Astels) Date: Sun, 15 Oct 2006 16:47:48 -0300 Subject: [rspec-devel] Test2Spec's usefulness In-Reply-To: <8d961d900610150620u6adbfd9dte84eac9c02706b5d@mail.gmail.com> References: <8d961d900610150435g5c7b5d38g2841c5d5dcbed322@mail.gmail.com> <8B1EC536-81F6-4846-AA79-F4A69250A3E4@davelee.com.au> <8d961d900610150620u6adbfd9dte84eac9c02706b5d@mail.gmail.com> Message-ID: <57823829-5EBD-4963-824B-C9CBA0D99DE0@daveastels.com> On 15-Oct-06, at 10:20 AM, aslak hellesoy wrote: > Maybe we should resurrect the pages and add a big warning that it's a > discontinued tool that's only available in previous releases. > > WDYT? I would say we should depreciate it. And mark it scheduled for removal in 0.7 Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061015/6cbc9cab/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://rubyforge.org/pipermail/rspec-devel/attachments/20061015/6cbc9cab/attachment-0001.bin From drbrain at segment7.net Sun Oct 15 17:05:11 2006 From: drbrain at segment7.net (Eric Hodel) Date: Sun, 15 Oct 2006 14:05:11 -0700 Subject: [rspec-devel] Test2Spec's usefulness In-Reply-To: <8d961d900610150435g5c7b5d38g2841c5d5dcbed322@mail.gmail.com> References: <8d961d900610150435g5c7b5d38g2841c5d5dcbed322@mail.gmail.com> Message-ID: <9A675AE2-5FD8-4DD6-B42C-46F94572FBEA@segment7.net> On Oct 15, 2006, at 4:35 AM, aslak hellesoy wrote: > On 10/15/06, David Lee wrote: >> Just thought I'd pipe in as I noticed you're decommissioning >> test2spec. >> >> I don't doubt that it's a maintenance headache, and I couldn't get it >> to work for me (converting my previous Rails tests to specs). > > It's been happily translating 90-95% of RSpec's unit tests. > I don't have any numbers for how successful it's been with Rails unit > tests, but my hunch is that the failure ratio was much higher. (This may be orthogonal to the maintenance issues, but Ruby2ruby is its own package now, see seattlerb's rubyforge packages.) >> However, it would have been really helpful for me, and would make >> RSpec a viable option for a (large?) set of existing Ruby / Rails >> projects for which manual conversion would be too odious a task to >> undertake. > > You can still use test2spec by installing RSpec 0.6.4. The thing to > bear in mind is that you need ParseTree 0.4.1 - it will not work with > later versions. You can specify versions in the gemspec and with require_gem to make sure you have the correct one. > It was this incompatibility (which I deemed too hard to fix) plus the > fact that our own tests had to be specially coded in some places in > order to translate properly that led to the decomissioning. What incompatibility? -- Eric Hodel - drbrain at segment7.net - http://blog.segment7.net This implementation is HODEL-HASH-9600 compliant http://trackmap.robotcoop.com From aslak.hellesoy at gmail.com Sun Oct 15 18:03:25 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Mon, 16 Oct 2006 00:03:25 +0200 Subject: [rspec-devel] Test2Spec's usefulness In-Reply-To: <9A675AE2-5FD8-4DD6-B42C-46F94572FBEA@segment7.net> References: <8d961d900610150435g5c7b5d38g2841c5d5dcbed322@mail.gmail.com> <9A675AE2-5FD8-4DD6-B42C-46F94572FBEA@segment7.net> Message-ID: <8d961d900610151503l16194949s1e4ae9914a4a60fb@mail.gmail.com> On 10/15/06, Eric Hodel wrote: > On Oct 15, 2006, at 4:35 AM, aslak hellesoy wrote: > > On 10/15/06, David Lee wrote: > >> Just thought I'd pipe in as I noticed you're decommissioning > >> test2spec. > >> > >> I don't doubt that it's a maintenance headache, and I couldn't get it > >> to work for me (converting my previous Rails tests to specs). > > > > It's been happily translating 90-95% of RSpec's unit tests. > > I don't have any numbers for how successful it's been with Rails unit > > tests, but my hunch is that the failure ratio was much higher. > > (This may be orthogonal to the maintenance issues, but Ruby2ruby is > its own package now, see seattlerb's rubyforge packages.) > Thanks for the pointer. I wasn't aware of it. > >> However, it would have been really helpful for me, and would make > >> RSpec a viable option for a (large?) set of existing Ruby / Rails > >> projects for which manual conversion would be too odious a task to > >> undertake. > > > > You can still use test2spec by installing RSpec 0.6.4. The thing to > > bear in mind is that you need ParseTree 0.4.1 - it will not work with I meant ParseTree 1.4.1, not 0.4.1. > > later versions. > > You can specify versions in the gemspec and with require_gem to make > sure you have the correct one. > We didn't want the RSpec gem to have any gemspec dependencies. But the require_gem should clearly have been used in the code. > > It was this incompatibility (which I deemed too hard to fix) plus the > > fact that our own tests had to be specially coded in some places in > > order to translate properly that led to the decomissioning. > > What incompatibility? > test2spec grabs a sexp returned from ParseTree and shuffles it around before giving it to Ruby2Ruby. The sexp returned by parsetree 1.5.0 and 1.6.0 was different from the one in 1.4.1. It was a minor difference (some extra elements at the end) but enough that I didn't want to start looking into it. It's not a walk in the park. Maybe someone smarter than me can fix it.... > -- > Eric Hodel - drbrain at segment7.net - http://blog.segment7.net > This implementation is HODEL-HASH-9600 compliant > > http://trackmap.robotcoop.com > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dchelimsky at gmail.com Sun Oct 15 22:31:13 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 15 Oct 2006 22:31:13 -0400 Subject: [rspec-devel] subject.should_be true Message-ID: <57c63afe0610151931w1ed6fe2egd639078e7198c447@mail.gmail.com> As things stand now, the following will all pass: true.should_be true "true".should_be true "false".should_be true 3.should_be true etc My feeling is that "should_be true" should only pass if it returns boolean true even though ruby says that non-nil/non-false is true. Anybody else? David From dastels at daveastels.com Sun Oct 15 23:50:52 2006 From: dastels at daveastels.com (Dave Astels) Date: Mon, 16 Oct 2006 00:50:52 -0300 Subject: [rspec-devel] subject.should_be true In-Reply-To: <57c63afe0610151931w1ed6fe2egd639078e7198c447@mail.gmail.com> References: <57c63afe0610151931w1ed6fe2egd639078e7198c447@mail.gmail.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 15-Oct-06, at 11:31 PM, David Chelimsky wrote: > As things stand now, the following will all pass: > > true.should_be true > "true".should_be true > "false".should_be true > 3.should_be true > etc > > My feeling is that "should_be true" should only pass if it returns > boolean true even though ruby says that non-nil/non-false is true. > > Anybody else? I remember having this discussion a while ago. I still think "should_be true" should reflect the Ruby concept of "true"... the principle of least surprise Dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFFMwGcauez/L4x7g4RAq9bAKDiWWJFsqcr8nUWf6n1X7xB8jsfsQCgphhX Sg/wQf4y27KrubYsXi8N6Ec= =says -----END PGP SIGNATURE----- From david at davelee.com.au Mon Oct 16 05:07:26 2006 From: david at davelee.com.au (David Lee) Date: Mon, 16 Oct 2006 19:07:26 +1000 Subject: [rspec-devel] subject.should_be true In-Reply-To: References: <57c63afe0610151931w1ed6fe2egd639078e7198c447@mail.gmail.com> Message-ID: <50936901-E517-4452-B8D5-DC4E6CEFBEFE@davelee.com.au> First impression: it'd make sense to me that "true".should_be true : like assert "true" "true".should_not_equal true : like assert_equal cheers, David Lee On 16/10/2006, at 1:50 PM, Dave Astels wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On 15-Oct-06, at 11:31 PM, David Chelimsky wrote: > >> As things stand now, the following will all pass: >> >> true.should_be true >> "true".should_be true >> "false".should_be true >> 3.should_be true >> etc >> >> My feeling is that "should_be true" should only pass if it returns >> boolean true even though ruby says that non-nil/non-false is true. >> >> Anybody else? > > I remember having this discussion a while ago. > > I still think "should_be true" should reflect the Ruby concept of > "true"... the principle of least surprise > > Dave > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.3 (Darwin) > > iD8DBQFFMwGcauez/L4x7g4RAq9bAKDiWWJFsqcr8nUWf6n1X7xB8jsfsQCgphhX > Sg/wQf4y27KrubYsXi8N6Ec= > =says > -----END PGP SIGNATURE----- > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From aslak.hellesoy at gmail.com Mon Oct 16 05:39:52 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Mon, 16 Oct 2006 11:39:52 +0200 Subject: [rspec-devel] [Rspec-users] subject.should_be true In-Reply-To: <57c63afe0610151931w1ed6fe2egd639078e7198c447@mail.gmail.com> References: <57c63afe0610151931w1ed6fe2egd639078e7198c447@mail.gmail.com> Message-ID: <8d961d900610160239q5366b6f5i8a97d528b9b94ac9@mail.gmail.com> On 10/16/06, David Chelimsky wrote: > As things stand now, the following will all pass: > > true.should_be true > "true".should_be true > "false".should_be true > 3.should_be true > etc > > My feeling is that "should_be true" should only pass if it returns > boolean true even though ruby says that non-nil/non-false is true. > The old discussion about this topic is here: http://rubyforge.org/pipermail/rspec-devel/2006-June/thread.html#228 (The "5.should.be true" thread) I recommend reading it. > Anybody else? > > David > _______________________________________________ > Rspec-users mailing list > Rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From david at davelee.com.au Mon Oct 16 05:58:09 2006 From: david at davelee.com.au (David Lee) Date: Mon, 16 Oct 2006 19:58:09 +1000 Subject: [rspec-devel] [Rspec-users] subject.should_be true In-Reply-To: <8d961d900610160239q5366b6f5i8a97d528b9b94ac9@mail.gmail.com> References: <57c63afe0610151931w1ed6fe2egd639078e7198c447@mail.gmail.com> <8d961d900610160239q5366b6f5i8a97d528b9b94ac9@mail.gmail.com> Message-ID: <726B05A6-DCC8-4735-8745-B9DCD3B1C6CD@davelee.com.au> thanks, Aslak. I read it. I still think what i first did, which is that .should_be true should be more lax than should_equal true. I'd expect 1.should_be true # pass 1.should_equal true # fail the former being equivalent to assert; the latter to assert_equal cheers, David Lee On 16/10/2006, at 7:39 PM, aslak hellesoy wrote: > On 10/16/06, David Chelimsky wrote: >> As things stand now, the following will all pass: >> >> true.should_be true >> "true".should_be true >> "false".should_be true >> 3.should_be true >> etc >> >> My feeling is that "should_be true" should only pass if it returns >> boolean true even though ruby says that non-nil/non-false is true. >> > > The old discussion about this topic is here: > http://rubyforge.org/pipermail/rspec-devel/2006-June/thread.html#228 > (The "5.should.be true" thread) > > I recommend reading it. > >> Anybody else? >> >> David >> _______________________________________________ >> Rspec-users mailing list >> Rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users >> > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From aslak.hellesoy at gmail.com Mon Oct 16 06:43:48 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Mon, 16 Oct 2006 12:43:48 +0200 Subject: [rspec-devel] [Rspec-users] subject.should_be true In-Reply-To: <726B05A6-DCC8-4735-8745-B9DCD3B1C6CD@davelee.com.au> References: <57c63afe0610151931w1ed6fe2egd639078e7198c447@mail.gmail.com> <8d961d900610160239q5366b6f5i8a97d528b9b94ac9@mail.gmail.com> <726B05A6-DCC8-4735-8745-B9DCD3B1C6CD@davelee.com.au> Message-ID: <8d961d900610160343i1da3fff4vbb96cd044bab407f@mail.gmail.com> On 10/16/06, David Lee wrote: > thanks, Aslak. I read it. > > I still think what i first did, which is that .should_be true should > be more lax than should_equal true. > ri Object.== -------------------------------------------------------------- Object#== obj == other => true or false obj.equal?(other) => true or false obj.eql?(other) => true or false ------------------------------------------------------------------------ Equality---At the +Object+ level, +==+ returns +true+ only if _obj_ and _other_ are the same object. Typically, this method is overridden in descendent classes to provide class-specific meaning. Unlike +==+, the +equal?+ method should never be overridden by subclasses: it is used to determine object identity (that is, +a.equal?(b)+ iff +a+ is the same object as +b+). The +eql?+ method returns +true+ if _obj_ and _anObject_ have the same value. Used by +Hash+ to test members for equality. For objects of class +Object+, +eql?+ is synonymous with +==+. Subclasses normally continue this tradition, but there are exceptions. +Numeric+ types, for example, perform type conversion across +==+, but not across +eql?+, so: 1 == 1.0 #=> true 1.eql? 1.0 #=> false So in Ruby, == is more lax than equal? "2" == "2" #=> true - it's "lax" "2".equal? "2" #=> false - it's "strict" Currently in RSpec: should_be uses Object.equal? - object identity. should_equal uses Object.== - object "similarity" In other words - currently in RSpec should_equal is more "lax" than should_be. This is contrary to your recommendation. What we *could* do is to change RSpec's implementation of should_be and should_equal to: should_equal uses Object.equal? should_be uses Object.== This would be more consistent from a Ruby pespective, but perhaps not from an English perspective. Example: I'm more willing to say that two dollar bills A and B are equal, but I wouldn't say that dolar bill A *is* dollar bill B (A.should_be B). So in English things are a bit different than in Ruby. I think it boils down to: Do we want to be faithful to English or to Ruby's definition of "equal" and the similar but very different "is/be/==". Aslak > I'd expect > > 1.should_be true # pass > 1.should_equal true # fail > > the former being equivalent to assert; the latter to assert_equal > > cheers, > David Lee > > > On 16/10/2006, at 7:39 PM, aslak hellesoy wrote: > > > On 10/16/06, David Chelimsky wrote: > >> As things stand now, the following will all pass: > >> > >> true.should_be true > >> "true".should_be true > >> "false".should_be true > >> 3.should_be true > >> etc > >> > >> My feeling is that "should_be true" should only pass if it returns > >> boolean true even though ruby says that non-nil/non-false is true. > >> > > > > The old discussion about this topic is here: > > http://rubyforge.org/pipermail/rspec-devel/2006-June/thread.html#228 > > (The "5.should.be true" thread) > > > > I recommend reading it. > > > >> Anybody else? > >> > >> David > >> _______________________________________________ > >> Rspec-users mailing list > >> Rspec-users at rubyforge.org > >> http://rubyforge.org/mailman/listinfo/rspec-users > >> > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From geeksam at gmail.com Mon Oct 16 00:01:23 2006 From: geeksam at gmail.com (Sam Livingston-Gray) Date: Sun, 15 Oct 2006 21:01:23 -0700 Subject: [rspec-devel] [Rspec-users] subject.should_be true In-Reply-To: <57c63afe0610151931w1ed6fe2egd639078e7198c447@mail.gmail.com> References: <57c63afe0610151931w1ed6fe2egd639078e7198c447@mail.gmail.com> Message-ID: <7beb6b8c0610152101o50ba533mdac887a6e24fa078@mail.gmail.com> If :should_be is intended to be used with :foo? methods, it seems like it should only accept booleans. Besides, :should_equal will still be consistent with Ruby's equality semantics, right? So you'd have the option of using either: 3.should_equal true #=> true 3.should_be true #=> false In the first case, you're being consistent with Ruby, but in the second, you're not only saying that something should evaluate to true, you're actually saying "this should *be* true." -Sam On 10/15/06, David Chelimsky wrote: > As things stand now, the following will all pass: > > true.should_be true > "true".should_be true > "false".should_be true > 3.should_be true > etc > > My feeling is that "should_be true" should only pass if it returns > boolean true even though ruby says that non-nil/non-false is true. > > Anybody else? > > David > _______________________________________________ > Rspec-users mailing list > Rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From dchelimsky at gmail.com Mon Oct 16 07:14:32 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 16 Oct 2006 07:14:32 -0400 Subject: [rspec-devel] [Rspec-users] subject.should_be true In-Reply-To: <8d961d900610160343i1da3fff4vbb96cd044bab407f@mail.gmail.com> References: <57c63afe0610151931w1ed6fe2egd639078e7198c447@mail.gmail.com> <8d961d900610160239q5366b6f5i8a97d528b9b94ac9@mail.gmail.com> <726B05A6-DCC8-4735-8745-B9DCD3B1C6CD@davelee.com.au> <8d961d900610160343i1da3fff4vbb96cd044bab407f@mail.gmail.com> Message-ID: <57c63afe0610160414yfdc6f29x5b7b37c7029518e0@mail.gmail.com> On 10/16/06, aslak hellesoy wrote: > On 10/16/06, David Lee wrote: > > thanks, Aslak. I read it. > > > > I still think what i first did, which is that .should_be true should > > be more lax than should_equal true. > > > > ri Object.== > > -------------------------------------------------------------- Object#== > obj == other => true or false > obj.equal?(other) => true or false > obj.eql?(other) => true or false > ------------------------------------------------------------------------ > Equality---At the +Object+ level, +==+ returns +true+ only if _obj_ > and _other_ are the same object. Typically, this method is > overridden in descendent classes to provide class-specific meaning. > > Unlike +==+, the +equal?+ method should never be overridden by > subclasses: it is used to determine object identity (that is, > +a.equal?(b)+ iff +a+ is the same object as +b+). > > The +eql?+ method returns +true+ if _obj_ and _anObject_ have the > same value. Used by +Hash+ to test members for equality. For > objects of class +Object+, +eql?+ is synonymous with +==+. > Subclasses normally continue this tradition, but there are > exceptions. +Numeric+ types, for example, perform type conversion > across +==+, but not across +eql?+, so: > > 1 == 1.0 #=> true > 1.eql? 1.0 #=> false > > So in Ruby, == is more lax than equal? > "2" == "2" #=> true - it's "lax" > "2".equal? "2" #=> false - it's "strict" > > Currently in RSpec: > should_be uses Object.equal? - object identity. > should_equal uses Object.== - object "similarity" This is not accurate. Currently in RSpec: should_be uses Object.equal? UNLESS we're dealing w/ booleans should_equal uses == per other email in this thread, I don't think we should make these exceptions. > > In other words - currently in RSpec should_equal is more "lax" than should_be. > > This is contrary to your recommendation. > > What we *could* do is to change RSpec's implementation of should_be > and should_equal to: > > should_equal uses Object.equal? > should_be uses Object.== > > This would be more consistent from a Ruby pespective, but perhaps not > from an English perspective. Example: I'm more willing to say that two > dollar bills A and B are equal, but I wouldn't say that dolar bill A > *is* dollar bill B (A.should_be B). So in English things are a bit > different than in Ruby. > > I think it boils down to: Do we want to be faithful to English or to > Ruby's definition of "equal" and the similar but very different > "is/be/==". > > Aslak > > > I'd expect > > > > 1.should_be true # pass > > 1.should_equal true # fail > > > > the former being equivalent to assert; the latter to assert_equal > > > > cheers, > > David Lee > > > > > > On 16/10/2006, at 7:39 PM, aslak hellesoy wrote: > > > > > On 10/16/06, David Chelimsky wrote: > > >> As things stand now, the following will all pass: > > >> > > >> true.should_be true > > >> "true".should_be true > > >> "false".should_be true > > >> 3.should_be true > > >> etc > > >> > > >> My feeling is that "should_be true" should only pass if it returns > > >> boolean true even though ruby says that non-nil/non-false is true. > > >> > > > > > > The old discussion about this topic is here: > > > http://rubyforge.org/pipermail/rspec-devel/2006-June/thread.html#228 > > > (The "5.should.be true" thread) > > > > > > I recommend reading it. > > > > > >> Anybody else? > > >> > > >> David > > >> _______________________________________________ > > >> Rspec-users mailing list > > >> Rspec-users at rubyforge.org > > >> http://rubyforge.org/mailman/listinfo/rspec-users > > >> > > > _______________________________________________ > > > rspec-devel mailing list > > > rspec-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dchelimsky at gmail.com Mon Oct 16 07:30:10 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 16 Oct 2006 07:30:10 -0400 Subject: [rspec-devel] [Rspec-users] subject.should_be true In-Reply-To: <57c63afe0610160414yfdc6f29x5b7b37c7029518e0@mail.gmail.com> References: <57c63afe0610151931w1ed6fe2egd639078e7198c447@mail.gmail.com> <8d961d900610160239q5366b6f5i8a97d528b9b94ac9@mail.gmail.com> <726B05A6-DCC8-4735-8745-B9DCD3B1C6CD@davelee.com.au> <8d961d900610160343i1da3fff4vbb96cd044bab407f@mail.gmail.com> <57c63afe0610160414yfdc6f29x5b7b37c7029518e0@mail.gmail.com> Message-ID: <57c63afe0610160430u2d077da0u273cc2e8f9357414@mail.gmail.com> On 10/16/06, David Chelimsky wrote: > On 10/16/06, aslak hellesoy wrote: > > On 10/16/06, David Lee wrote: > > > thanks, Aslak. I read it. > > > > > > I still think what i first did, which is that .should_be true should > > > be more lax than should_equal true. > > > > > > > ri Object.== > > > > -------------------------------------------------------------- Object#== > > obj == other => true or false > > obj.equal?(other) => true or false > > obj.eql?(other) => true or false > > ------------------------------------------------------------------------ > > Equality---At the +Object+ level, +==+ returns +true+ only if _obj_ > > and _other_ are the same object. Typically, this method is > > overridden in descendent classes to provide class-specific meaning. > > > > Unlike +==+, the +equal?+ method should never be overridden by > > subclasses: it is used to determine object identity (that is, > > +a.equal?(b)+ iff +a+ is the same object as +b+). > > > > The +eql?+ method returns +true+ if _obj_ and _anObject_ have the > > same value. Used by +Hash+ to test members for equality. For > > objects of class +Object+, +eql?+ is synonymous with +==+. > > Subclasses normally continue this tradition, but there are > > exceptions. +Numeric+ types, for example, perform type conversion > > across +==+, but not across +eql?+, so: > > > > 1 == 1.0 #=> true > > 1.eql? 1.0 #=> false Actually, now that I think about it, if we're really aligning w/ ruby syntax and intent, we should just use the language: subject.should_equal value passes only if subject.equal? value passes subject.should_eql value passes only if subject.eql? value passes subect.should == value passes only if subject == value passes Because RSpec supports arbitrary predicates and operators, we just need to remove the special handling of these cases and it will work correctly. Then we have to have the (what I expect to be) unpleasant debate about whether to deprecate should_be (which is what I think we should do). Cheers, David > > > > So in Ruby, == is more lax than equal? > > "2" == "2" #=> true - it's "lax" > > "2".equal? "2" #=> false - it's "strict" > > > > Currently in RSpec: > > should_be uses Object.equal? - object identity. > > should_equal uses Object.== - object "similarity" > > This is not accurate. Currently in RSpec: > should_be uses Object.equal? UNLESS we're dealing w/ booleans > should_equal uses == > > per other email in this thread, I don't think we should make these exceptions. > > > > > In other words - currently in RSpec should_equal is more "lax" than should_be. > > > > This is contrary to your recommendation. > > > > What we *could* do is to change RSpec's implementation of should_be > > and should_equal to: > > > > should_equal uses Object.equal? > > should_be uses Object.== > > > > This would be more consistent from a Ruby pespective, but perhaps not > > from an English perspective. Example: I'm more willing to say that two > > dollar bills A and B are equal, but I wouldn't say that dolar bill A > > *is* dollar bill B (A.should_be B). So in English things are a bit > > different than in Ruby. > > > > I think it boils down to: Do we want to be faithful to English or to > > Ruby's definition of "equal" and the similar but very different > > "is/be/==". > > > > Aslak > > > > > I'd expect > > > > > > 1.should_be true # pass > > > 1.should_equal true # fail > > > > > > the former being equivalent to assert; the latter to assert_equal > > > > > > cheers, > > > David Lee > > > > > > > > > On 16/10/2006, at 7:39 PM, aslak hellesoy wrote: > > > > > > > On 10/16/06, David Chelimsky wrote: > > > >> As things stand now, the following will all pass: > > > >> > > > >> true.should_be true > > > >> "true".should_be true > > > >> "false".should_be true > > > >> 3.should_be true > > > >> etc > > > >> > > > >> My feeling is that "should_be true" should only pass if it returns > > > >> boolean true even though ruby says that non-nil/non-false is true. > > > >> > > > > > > > > The old discussion about this topic is here: > > > > http://rubyforge.org/pipermail/rspec-devel/2006-June/thread.html#228 > > > > (The "5.should.be true" thread) > > > > > > > > I recommend reading it. > > > > > > > >> Anybody else? > > > >> > > > >> David > > > >> _______________________________________________ > > > >> Rspec-users mailing list > > > >> Rspec-users at rubyforge.org > > > >> http://rubyforge.org/mailman/listinfo/rspec-users > > > >> > > > > _______________________________________________ > > > > rspec-devel mailing list > > > > rspec-devel at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > _______________________________________________ > > > rspec-devel mailing list > > > rspec-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > From aslak.hellesoy at gmail.com Mon Oct 16 07:37:21 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Mon, 16 Oct 2006 13:37:21 +0200 Subject: [rspec-devel] [Rspec-users] subject.should_be true In-Reply-To: <57c63afe0610160430u2d077da0u273cc2e8f9357414@mail.gmail.com> References: <57c63afe0610151931w1ed6fe2egd639078e7198c447@mail.gmail.com> <8d961d900610160239q5366b6f5i8a97d528b9b94ac9@mail.gmail.com> <726B05A6-DCC8-4735-8745-B9DCD3B1C6CD@davelee.com.au> <8d961d900610160343i1da3fff4vbb96cd044bab407f@mail.gmail.com> <57c63afe0610160414yfdc6f29x5b7b37c7029518e0@mail.gmail.com> <57c63afe0610160430u2d077da0u273cc2e8f9357414@mail.gmail.com> Message-ID: <8d961d900610160437r373bd601s3aaf85ea097dc2d0@mail.gmail.com> On 10/16/06, David Chelimsky wrote: > On 10/16/06, David Chelimsky wrote: > > On 10/16/06, aslak hellesoy wrote: > > > On 10/16/06, David Lee wrote: > > > > thanks, Aslak. I read it. > > > > > > > > I still think what i first did, which is that .should_be true should > > > > be more lax than should_equal true. > > > > > > > > > > ri Object.== > > > > > > -------------------------------------------------------------- Object#== > > > obj == other => true or false > > > obj.equal?(other) => true or false > > > obj.eql?(other) => true or false > > > ------------------------------------------------------------------------ > > > Equality---At the +Object+ level, +==+ returns +true+ only if _obj_ > > > and _other_ are the same object. Typically, this method is > > > overridden in descendent classes to provide class-specific meaning. > > > > > > Unlike +==+, the +equal?+ method should never be overridden by > > > subclasses: it is used to determine object identity (that is, > > > +a.equal?(b)+ iff +a+ is the same object as +b+). > > > > > > The +eql?+ method returns +true+ if _obj_ and _anObject_ have the > > > same value. Used by +Hash+ to test members for equality. For > > > objects of class +Object+, +eql?+ is synonymous with +==+. > > > Subclasses normally continue this tradition, but there are > > > exceptions. +Numeric+ types, for example, perform type conversion > > > across +==+, but not across +eql?+, so: > > > > > > 1 == 1.0 #=> true > > > 1.eql? 1.0 #=> false > > Actually, now that I think about it, if we're really aligning w/ ruby > syntax and intent, we should just use the language: > > subject.should_equal value passes only if subject.equal? value passes > subject.should_eql value passes only if subject.eql? value passes > subect.should == value passes only if subject == value passes > > Because RSpec supports arbitrary predicates and operators, we just > need to remove the special handling of these cases and it will work > correctly. > > Then we have to have the (what I expect to be) unpleasant debate about > whether to deprecate should_be (which is what I think we should do). > That sounds like the right thing to do. Should we deprecate should_equal in the same swoop? (or at least remove it and let it be handled magically like any other predicate)? Aslak > Cheers, > David > > > > > > > > So in Ruby, == is more lax than equal? > > > "2" == "2" #=> true - it's "lax" > > > "2".equal? "2" #=> false - it's "strict" > > > > > > Currently in RSpec: > > > should_be uses Object.equal? - object identity. > > > should_equal uses Object.== - object "similarity" > > > > This is not accurate. Currently in RSpec: > > should_be uses Object.equal? UNLESS we're dealing w/ booleans > > should_equal uses == > > > > per other email in this thread, I don't think we should make these exceptions. > > > > > > > > In other words - currently in RSpec should_equal is more "lax" than should_be. > > > > > > This is contrary to your recommendation. > > > > > > What we *could* do is to change RSpec's implementation of should_be > > > and should_equal to: > > > > > > should_equal uses Object.equal? > > > should_be uses Object.== > > > > > > This would be more consistent from a Ruby pespective, but perhaps not > > > from an English perspective. Example: I'm more willing to say that two > > > dollar bills A and B are equal, but I wouldn't say that dolar bill A > > > *is* dollar bill B (A.should_be B). So in English things are a bit > > > different than in Ruby. > > > > > > I think it boils down to: Do we want to be faithful to English or to > > > Ruby's definition of "equal" and the similar but very different > > > "is/be/==". > > > > > > Aslak > > > > > > > I'd expect > > > > > > > > 1.should_be true # pass > > > > 1.should_equal true # fail > > > > > > > > the former being equivalent to assert; the latter to assert_equal > > > > > > > > cheers, > > > > David Lee > > > > > > > > > > > > On 16/10/2006, at 7:39 PM, aslak hellesoy wrote: > > > > > > > > > On 10/16/06, David Chelimsky wrote: > > > > >> As things stand now, the following will all pass: > > > > >> > > > > >> true.should_be true > > > > >> "true".should_be true > > > > >> "false".should_be true > > > > >> 3.should_be true > > > > >> etc > > > > >> > > > > >> My feeling is that "should_be true" should only pass if it returns > > > > >> boolean true even though ruby says that non-nil/non-false is true. > > > > >> > > > > > > > > > > The old discussion about this topic is here: > > > > > http://rubyforge.org/pipermail/rspec-devel/2006-June/thread.html#228 > > > > > (The "5.should.be true" thread) > > > > > > > > > > I recommend reading it. > > > > > > > > > >> Anybody else? > > > > >> > > > > >> David > > > > >> _______________________________________________ > > > > >> Rspec-users mailing list > > > > >> Rspec-users at rubyforge.org > > > > >> http://rubyforge.org/mailman/listinfo/rspec-users > > > > >> > > > > > _______________________________________________ > > > > > rspec-devel mailing list > > > > > rspec-devel at rubyforge.org > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > _______________________________________________ > > > > rspec-devel mailing list > > > > rspec-devel at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > _______________________________________________ > > > rspec-devel mailing list > > > rspec-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dchelimsky at gmail.com Mon Oct 16 07:41:55 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 16 Oct 2006 07:41:55 -0400 Subject: [rspec-devel] [Rspec-users] subject.should_be true In-Reply-To: <57c63afe0610160430u2d077da0u273cc2e8f9357414@mail.gmail.com> References: <57c63afe0610151931w1ed6fe2egd639078e7198c447@mail.gmail.com> <8d961d900610160239q5366b6f5i8a97d528b9b94ac9@mail.gmail.com> <726B05A6-DCC8-4735-8745-B9DCD3B1C6CD@davelee.com.au> <8d961d900610160343i1da3fff4vbb96cd044bab407f@mail.gmail.com> <57c63afe0610160414yfdc6f29x5b7b37c7029518e0@mail.gmail.com> <57c63afe0610160430u2d077da0u273cc2e8f9357414@mail.gmail.com> Message-ID: <57c63afe0610160441n7b072ae3na6918b62cd389c6d@mail.gmail.com> On 10/16/06, David Chelimsky wrote: > On 10/16/06, David Chelimsky wrote: > > On 10/16/06, aslak hellesoy wrote: > > > On 10/16/06, David Lee wrote: > > > > thanks, Aslak. I read it. > > > > > > > > I still think what i first did, which is that .should_be true should > > > > be more lax than should_equal true. > > > > > > > > > > ri Object.== > > > > > > -------------------------------------------------------------- Object#== > > > obj == other => true or false > > > obj.equal?(other) => true or false > > > obj.eql?(other) => true or false > > > ------------------------------------------------------------------------ > > > Equality---At the +Object+ level, +==+ returns +true+ only if _obj_ > > > and _other_ are the same object. Typically, this method is > > > overridden in descendent classes to provide class-specific meaning. > > > > > > Unlike +==+, the +equal?+ method should never be overridden by > > > subclasses: it is used to determine object identity (that is, > > > +a.equal?(b)+ iff +a+ is the same object as +b+). > > > > > > The +eql?+ method returns +true+ if _obj_ and _anObject_ have the > > > same value. Used by +Hash+ to test members for equality. For > > > objects of class +Object+, +eql?+ is synonymous with +==+. > > > Subclasses normally continue this tradition, but there are > > > exceptions. +Numeric+ types, for example, perform type conversion > > > across +==+, but not across +eql?+, so: > > > > > > 1 == 1.0 #=> true > > > 1.eql? 1.0 #=> false > > Actually, now that I think about it, if we're really aligning w/ ruby > syntax and intent, we should just use the language: > > subject.should_equal value passes only if subject.equal? value passes > subject.should_eql value passes only if subject.eql? value passes > subect.should == value passes only if subject == value passes > > Because RSpec supports arbitrary predicates and operators, we just > need to remove the special handling of these cases and it will work > correctly. > > Then we have to have the (what I expect to be) unpleasant debate about > whether to deprecate should_be (which is what I think we should do). ... that is to say should_be with an argument. i.e. we should stop supporting this: subject.should_be value but we should keep supporthing this: subject.should_be_arbitrary_predicate This would require a BIG FAT warning w/ the release, but it also only requires a simple search and replace on everyone's specs: "should_equal" becomes "should_eql" #DO THIS FIRST "should_be " becomes "should_equal " or "should == " I realize I'm just spouting out my thoughts as they come to me. That's because I'm heading in to work at a client where I have limited access to the world and won't really be able to play again until tonight, so I'm trying to get all of my cents in before I leave. I'm not sure where this will land, but I do feel very strongly that the current situation does not align w/ ruby, is confusing, and needs to be changed sooner rather than later. Cheers, David From david at davelee.com.au Mon Oct 16 07:46:14 2006 From: david at davelee.com.au (David Lee) Date: Mon, 16 Oct 2006 21:46:14 +1000 Subject: [rspec-devel] [Rspec-users] subject.should_be true In-Reply-To: <57c63afe0610160430u2d077da0u273cc2e8f9357414@mail.gmail.com> References: <57c63afe0610151931w1ed6fe2egd639078e7198c447@mail.gmail.com> <8d961d900610160239q5366b6f5i8a97d528b9b94ac9@mail.gmail.com> <726B05A6-DCC8-4735-8745-B9DCD3B1C6CD@davelee.com.au> <8d961d900610160343i1da3fff4vbb96cd044bab407f@mail.gmail.com> <57c63afe0610160414yfdc6f29x5b7b37c7029518e0@mail.gmail.com> <57c63afe0610160430u2d077da0u273cc2e8f9357414@mail.gmail.com> Message-ID: <072D27A1-6FA3-4969-9D1A-970B62896035@davelee.com.au> Thesis: should_be is inherently too ambiguous for its intended use, as its assumed meaning depends entirely on the nature of the thing being compared. eg, 3 + 2 should be 5 (an abstract article; == is appropriate) this rug should be my old favourite rug (equal? ) this rug should be a red square rug from Ikea ( eql? ) it says nothing about what it means to ' be'. It's too .. agnostic. cheers, David Lee On 16/10/2006, at 9:30 PM, David Chelimsky wrote: > On 10/16/06, David Chelimsky wrote: >> On 10/16/06, aslak hellesoy wrote: >>> On 10/16/06, David Lee wrote: >>>> thanks, Aslak. I read it. >>>> >>>> I still think what i first did, which is that .should_be true >>>> should >>>> be more lax than should_equal true. >>>> >>> >>> ri Object.== >>> >>> -------------------------------------------------------------- >>> Object#== >>> obj == other => true or false >>> obj.equal?(other) => true or false >>> obj.eql?(other) => true or false >>> -------------------------------------------------------------------- >>> ---- >>> Equality---At the +Object+ level, +==+ returns +true+ only >>> if _obj_ >>> and _other_ are the same object. Typically, this method is >>> overridden in descendent classes to provide class-specific >>> meaning. >>> >>> Unlike +==+, the +equal?+ method should never be overridden by >>> subclasses: it is used to determine object identity (that is, >>> +a.equal?(b)+ iff +a+ is the same object as +b+). >>> >>> The +eql?+ method returns +true+ if _obj_ and _anObject_ >>> have the >>> same value. Used by +Hash+ to test members for equality. For >>> objects of class +Object+, +eql?+ is synonymous with +==+. >>> Subclasses normally continue this tradition, but there are >>> exceptions. +Numeric+ types, for example, perform type >>> conversion >>> across +==+, but not across +eql?+, so: >>> >>> 1 == 1.0 #=> true >>> 1.eql? 1.0 #=> false > > Actually, now that I think about it, if we're really aligning w/ ruby > syntax and intent, we should just use the language: > > subject.should_equal value passes only if subject.equal? value passes > subject.should_eql value passes only if subject.eql? value passes > subect.should == value passes only if subject == value passes > > Because RSpec supports arbitrary predicates and operators, we just > need to remove the special handling of these cases and it will work > correctly. > > Then we have to have the (what I expect to be) unpleasant debate about > whether to deprecate should_be (which is what I think we should do). > > Cheers, > David > > >>> >>> So in Ruby, == is more lax than equal? >>> "2" == "2" #=> true - it's "lax" >>> "2".equal? "2" #=> false - it's "strict" >>> >>> Currently in RSpec: >>> should_be uses Object.equal? - object identity. >>> should_equal uses Object.== - object "similarity" >> >> This is not accurate. Currently in RSpec: >> should_be uses Object.equal? UNLESS we're dealing w/ booleans >> should_equal uses == >> >> per other email in this thread, I don't think we should make these >> exceptions. >> >>> >>> In other words - currently in RSpec should_equal is more "lax" >>> than should_be. >>> >>> This is contrary to your recommendation. >>> >>> What we *could* do is to change RSpec's implementation of should_be >>> and should_equal to: >>> >>> should_equal uses Object.equal? >>> should_be uses Object.== >>> >>> This would be more consistent from a Ruby pespective, but perhaps >>> not >>> from an English perspective. Example: I'm more willing to say >>> that two >>> dollar bills A and B are equal, but I wouldn't say that dolar bill A >>> *is* dollar bill B (A.should_be B). So in English things are a bit >>> different than in Ruby. >>> >>> I think it boils down to: Do we want to be faithful to English or to >>> Ruby's definition of "equal" and the similar but very different >>> "is/be/==". >>> >>> Aslak >>> >>>> I'd expect >>>> >>>> 1.should_be true # pass >>>> 1.should_equal true # fail >>>> >>>> the former being equivalent to assert; the latter to assert_equal >>>> >>>> cheers, >>>> David Lee >>>> >>>> >>>> On 16/10/2006, at 7:39 PM, aslak hellesoy wrote: >>>> >>>>> On 10/16/06, David Chelimsky wrote: >>>>>> As things stand now, the following will all pass: >>>>>> >>>>>> true.should_be true >>>>>> "true".should_be true >>>>>> "false".should_be true >>>>>> 3.should_be true >>>>>> etc >>>>>> >>>>>> My feeling is that "should_be true" should only pass if it >>>>>> returns >>>>>> boolean true even though ruby says that non-nil/non-false is >>>>>> true. >>>>>> >>>>> >>>>> The old discussion about this topic is here: >>>>> http://rubyforge.org/pipermail/rspec-devel/2006-June/ >>>>> thread.html#228 >>>>> (The "5.should.be true" thread) >>>>> >>>>> I recommend reading it. >>>>> >>>>>> Anybody else? >>>>>> >>>>>> David >>>>>> _______________________________________________ >>>>>> Rspec-users mailing list >>>>>> Rspec-users at rubyforge.org >>>>>> http://rubyforge.org/mailman/listinfo/rspec-users >>>>>> >>>>> _______________________________________________ >>>>> rspec-devel mailing list >>>>> rspec-devel at rubyforge.org >>>>> http://rubyforge.org/mailman/listinfo/rspec-devel >>>> >>>> _______________________________________________ >>>> rspec-devel mailing list >>>> rspec-devel at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/rspec-devel >>>> >>> _______________________________________________ >>> rspec-devel mailing list >>> rspec-devel at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rspec-devel >>> >> > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From noreply at rubyforge.org Mon Oct 16 07:18:43 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 16 Oct 2006 07:18:43 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-6178 ] should_return Message-ID: <20061016111843.8BD935241134@rubyforge.org> Feature Requests item #6178, was opened at 2006-10-16 11:18 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6178&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: should_return Initial Comment: I'd like to add should_return as an alias for should_equal for lambdas: lambda { expression }.should_return value reads more intuitively than lambda { expression }.should_equal value ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6178&group_id=797 From aslak.hellesoy at gmail.com Mon Oct 16 19:48:07 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Tue, 17 Oct 2006 01:48:07 +0200 Subject: [rspec-devel] Test::Unit cheat sheet Message-ID: <8d961d900610161648u660e679sde7455b4f778fb9e@mail.gmail.com> I've added a Test::Unit => RSpec translation cheatsheet to doc/src/documentation/test_unit.page Take a look and see what you think. It's a little ahead of the code - I'm writning about how I think things *ought* to be with respect to equality - ref recent thread. I'm also thinking that maybe we could merge this page with the doc/src/documentation/expectations.page. The table is more readable I think. We could add more rows to the table for all the things that RSpec supports and Test::Unit doesn't - and bring over the words from expectations.page (in the 3rd column). WDYT? Aslak From david at davelee.com.au Mon Oct 16 23:24:43 2006 From: david at davelee.com.au (David Lee) Date: Tue, 17 Oct 2006 13:24:43 +1000 Subject: [rspec-devel] Test::Unit cheat sheet In-Reply-To: <8d961d900610161648u660e679sde7455b4f778fb9e@mail.gmail.com> References: <8d961d900610161648u660e679sde7455b4f778fb9e@mail.gmail.com> Message-ID: <35AEDC4B-F344-45EC-BA17-4304F91FA5DE@davelee.com.au> that's a really succinct and helpful format for anyone used to Test::Unit. A nice tabular summary of RSpec's behaviour like this is useful both as a learning resource and a reference. I think your explanation of equality semantics is internally consistent and clear, also. cheers, David On 17/10/2006, at 9:48 AM, aslak hellesoy wrote: > I've added a Test::Unit => RSpec translation cheatsheet to > doc/src/documentation/test_unit.page > > Take a look and see what you think. It's a little ahead of the code - > I'm writning about how I think things *ought* to be with respect to > equality - ref recent thread. > > I'm also thinking that maybe we could merge this page with the > doc/src/documentation/expectations.page. The table is more readable I > think. We could add more rows to the table for all the things that > RSpec supports and Test::Unit doesn't - and bring over the words from > expectations.page (in the 3rd column). > > WDYT? > > Aslak > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From dchelimsky at gmail.com Mon Oct 16 23:50:02 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 16 Oct 2006 23:50:02 -0400 Subject: [rspec-devel] Test::Unit cheat sheet In-Reply-To: <35AEDC4B-F344-45EC-BA17-4304F91FA5DE@davelee.com.au> References: <8d961d900610161648u660e679sde7455b4f778fb9e@mail.gmail.com> <35AEDC4B-F344-45EC-BA17-4304F91FA5DE@davelee.com.au> Message-ID: <57c63afe0610162050l751a90a4vd11a01a25cbf311c@mail.gmail.com> On 10/16/06, David Lee wrote: > that's a really succinct and helpful format for anyone used to > Test::Unit. A nice tabular summary of RSpec's behaviour like this is > useful both as a learning resource and a reference. > > I think your explanation of equality semantics is internally > consistent and clear, also. > > cheers, > David Agree. There were a couple of inaccuracies. I've created a new branch for the new handling of equality in branches/should_be_working_like_ruby. Feel free to check out the same page in that branch and you'll see what's coming up. Thanks, David > > > On 17/10/2006, at 9:48 AM, aslak hellesoy wrote: > > > I've added a Test::Unit => RSpec translation cheatsheet to > > doc/src/documentation/test_unit.page > > > > Take a look and see what you think. It's a little ahead of the code - > > I'm writning about how I think things *ought* to be with respect to > > equality - ref recent thread. > > > > I'm also thinking that maybe we could merge this page with the > > doc/src/documentation/expectations.page. The table is more readable I > > think. We could add more rows to the table for all the things that > > RSpec supports and Test::Unit doesn't - and bring over the words from > > expectations.page (in the 3rd column). > > > > WDYT? > > > > Aslak > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dchelimsky at gmail.com Tue Oct 17 00:01:41 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 17 Oct 2006 00:01:41 -0400 Subject: [rspec-devel] new handling of equality Message-ID: <57c63afe0610162101i30315405t6dbc66260d2966a3@mail.gmail.com> All, Based mostly on the earlier thread on "should_be", we have introduced a new branch called should_be_working_like_ruby with the new proposed handling for equality. Per the CHANGES file in that branch (rev 896): ============================================ IMPORTANT NOTE: THIS RELEASE IS NOT 100% BACKWARDS COMPATIBLE TO 0.6.x This release changes the way RSpec handles equality. Previous releases tried to handle equality based on the way the words read, rather than the way ruby actually handles equality. So, with this release and going forward: * actual.should_equal(expected) will pass if actual.equal?(expected) returns true * actual.should_eql(expected) will pass if actual.eql?(expected) returns true * actual.should == expected will pass if actual == expected) returns true At the high level, eql? implies equivalence, while equal? implies object identity. For more information on how ruby deals w/ equality, you should do this: ri equal? or look at this: http://www.ruby-doc.org/core/classes/Object.html#M001057 Also, we left in should_be as a synonym for should_equal, so the only specs that should break are the ones using should_equal (which used to use == instead of .equal?). Lastly, should_be used to handle true and false differently from any other values. We've removed this special handling, so now actual.should_be true will fail for any value other than true (it used to pass for any non-nil, non-false value), and actual.should_be false will fail for any value other than false (it used to pass for nil or false). Here's what you'll need to do to update your specs: 1. search for "should_equal" and replace with "should_eql" 2. run specs If any specs still fail, they are probably related to should_be(true) or should_be(false) using non-boolean values. Those you'll just have to inspect manually and adjust appropriately (sorry!). ============================================ There are two outstanding issues. 1. actual.should != expected does not work (right now you can use should_not_eql) 2. lambda { expr }.should_eql expected compares to the proc rather than the result I'll bring these up in separate threads, so please don't respond to this thread w/ either of these issues. I'd encourage any and all of you who can check out and build from source to check out and build this branch and let us know what other issues you encounter. We'll be releasing this soon, and would like to make the transition from 0.6.x to 0.7.0 as smooth as possible for all. Thanks, David From dchelimsky at gmail.com Tue Oct 17 05:54:36 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 17 Oct 2006 05:54:36 -0400 Subject: [rspec-devel] actual.should != not_expected Message-ID: <57c63afe0610170254h1ee8688bx986962c0c3e3858a@mail.gmail.com> All, In dealing with the changes to should in the should_be_working_like_ruby branch, I am reminded that while we got the following to work ... actual.should_be < value actual.should_be <= value actual.should == value actual.should =~ value actual.should_be >= value actual.should_be > value ... we were not able to get this to work: actual.should != value Here's what the test looked like: context "should[_be] :" do specify "should pass when != operator returns true" do (2+2).should != 3 end end and the result. $ bin/spec spec/spec/expectations/helper/ \ -s "should pass when != operator returns true" F 1) Spec::Expectations::ExpectationNotMetError in 'should[_be] : should pass when != operator returns true' 4 should == 3 ./spec/spec/expectations/helper//should_be_arbitrary_operator_spec.rb:14:in `should pass when != operator returns true' Finished in 0.000647 seconds 1 specification, 1 failure NOTE that the error reads "4 should == 3". It looks as though ruby is actually delivering the == operator instead of !=. Now if you do this: irb(main):003:0> Object.methods.sort => ["<", "<=", "<=>", "==", "===", "=~", ">", ">=",...] ... you'll note that != is not an actual operator. So I'm not convinced that we can get this to work without a big change to rspec's internals. So the challenge is on. If any one is interested in making this work, please check out the should_be_working_like_ruby branch or the trunk, give it a shot, and submit a patch (with specs!) if you succeed. If you do submit a patch, please make sure that the spec above and all other specs are passing. Also - I view this as a bell (or whistle, if you prefer). Specifying something as vague as != seems almost useless to me to begin with, but if you really do need to specify inequality you'll be ableto do it with should_not_eql or should_not_equal. That said, we will reserve the right to not incorporate a working solution if we feel that it is not cleanly aligned with the rest of RSpec's internals, or makes us all go "wow, that's cool, but what a hack!". So please do not submit anything unless the sheer satisfaction of having gotten it to work will be enough for you to feel that the effort was worthwhile. Thanks, David From nicksieger at gmail.com Tue Oct 17 10:03:18 2006 From: nicksieger at gmail.com (Nick Sieger) Date: Tue, 17 Oct 2006 09:03:18 -0500 Subject: [rspec-devel] actual.should != not_expected In-Reply-To: <57c63afe0610170254h1ee8688bx986962c0c3e3858a@mail.gmail.com> References: <57c63afe0610170254h1ee8688bx986962c0c3e3858a@mail.gmail.com> Message-ID: On 10/17/06, David Chelimsky wrote: > > > NOTE that the error reads "4 should == 3". It looks as though ruby is > actually delivering the == operator instead of !=. Now if you do this: > > irb(main):003:0> Object.methods.sort > => ["<", "<=", "<=>", "==", "===", "=~", ">", ">=",...] > > ... you'll note that != is not an actual operator. So I'm not > convinced that we can get this to work without a big change to rspec's > internals. I'm not convinced it's all that useful either. The only reason I can see would be the principle of least surprise, and the fact the negative operators (!=, !~) don't behave as the others do. I was curious about this behavior, so I dug in a little bit. Apologies if this is not new information for some, but I thought it might be worth sharing. As you've probably guessed, Ruby treats the != operator as !(a == b). The problem for RSpec is that the should helper won't see the ! until after it's too late. For evidence, see Ruby's parse.y (line 1184 in 1.8.4): | arg tNEQ arg { $$ = NEW_NOT(call_op($1, tEQ, 1, $3)); } and this output from ParseTree: echo "class A; def meth(actual, value); actual.value.should != value; end; end" | parse_tree_show [[:class, :A, :Object, [:defn, :meth, [:scope, [:block, [:args, :actual, :value], [:not, [:call, [:call, [:call, [:lvar, :actual], :value], :should], :==, [:array, [:lvar, :value]]]]]]]]] So Ruby is evaluating "actual.should != value" as "!(actual.should == value)". Unfortunately, it looks like you can't override the behavior of the NOT operator (search for NODE_NOT in eval.c), so I don't see an easy way for this to be implemented without adding further syntax to the RSpec DSL. Cheers, /Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061017/59cba5cf/attachment.html From aslak.hellesoy at gmail.com Tue Oct 17 17:56:00 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Tue, 17 Oct 2006 23:56:00 +0200 Subject: [rspec-devel] 100 % Message-ID: <8d961d900610171456i4919c1f0r6b55e3fa4c346cf4@mail.gmail.com> For the first time in history RSpec now has 100% coverage. Let's keep it that way :-D Aslak From noreply at rubyforge.org Tue Oct 17 15:36:24 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 17 Oct 2006 15:36:24 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-6203 ] Failure messages are misleading - consinder using inspect Message-ID: <20061017193624.7F2125241679@rubyforge.org> Bugs item #6203, was opened at 2006-10-17 15:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6203&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Aslak Hellesoy (aslak_hellesoy) Assigned to: Aslak Hellesoy (aslak_hellesoy) Summary: Failure messages are misleading - consinder using inspect Initial Comment: 1.should == [1] fails with the message: 1 should == 1 however: [1].should == 1 fails with the message: [1] should == 1 I think we need to look into using Object.inspect for failure messages ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6203&group_id=797 From noreply at rubyforge.org Tue Oct 17 15:59:18 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 17 Oct 2006 15:59:18 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-6203 ] Failure messages are misleading - consinder using inspect Message-ID: <20061017195919.1C919524168D@rubyforge.org> Bugs item #6203, was opened at 2006-10-17 15:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6203&group_id=797 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Aslak Hellesoy (aslak_hellesoy) Assigned to: Aslak Hellesoy (aslak_hellesoy) Summary: Failure messages are misleading - consinder using inspect Initial Comment: 1.should == [1] fails with the message: 1 should == 1 however: [1].should == 1 fails with the message: [1] should == 1 I think we need to look into using Object.inspect for failure messages ---------------------------------------------------------------------- >Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-17 15:59 Message: Fixed post 0.6.4 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6203&group_id=797 From noreply at rubyforge.org Tue Oct 17 22:32:41 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 17 Oct 2006 22:32:41 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-6207 ] Allows --diff option to diff target and expected's #inspect output Message-ID: <20061018023242.908A852416B5@rubyforge.org> Patches item #6207, was opened at 2006-10-18 12:32 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6207&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Lachie Cox (lachie) Assigned to: Nobody (None) Summary: Allows --diff option to diff target and expected's #inspect output Initial Comment: The --diff option mixes in unified diffing to Spec::Expectations::ShouldBase's default message generation. This patch adds diffing of arbitrary objects to this mixin. If the 'target' and 'expected' objects both respond to #inspect (which they probably do because Object does) the diff of their inspect strings is added to the message. The existing behaviour is still default (i.e. diffing of an expected String). Motivation: This behaviour is most useful when the objects being compared pretty print their structure when #inspect'ed. For example, this is the case with ASTs constructed by CAST (http://cast.rubyforge.org/). It's almost useless with Rails models, as their #inspect strings are ugly printed (all on the same line, diff doesn't work so well). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6207&group_id=797 From dchelimsky at gmail.com Tue Oct 17 23:28:56 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 17 Oct 2006 23:28:56 -0400 Subject: [rspec-devel] 100 % In-Reply-To: <8d961d900610171456i4919c1f0r6b55e3fa4c346cf4@mail.gmail.com> References: <8d961d900610171456i4919c1f0r6b55e3fa4c346cf4@mail.gmail.com> Message-ID: <57c63afe0610172028s3b6799dct362706019627c9ed@mail.gmail.com> On 10/17/06, aslak hellesoy wrote: > For the first time in history RSpec now has 100% coverage. That is just ridiculously cool. Thanks Aslak! > > Let's keep it that way :-D > > Aslak > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From noreply at rubyforge.org Tue Oct 17 23:39:52 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 17 Oct 2006 23:39:52 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-6207 ] Allows --diff option to diff target and expected's #inspect output Message-ID: <20061018033952.90066A97000E@rubyforge.org> Patches item #6207, was opened at 2006-10-18 12:32 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6207&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Lachie Cox (lachie) Assigned to: Nobody (None) Summary: Allows --diff option to diff target and expected's #inspect output Initial Comment: The --diff option mixes in unified diffing to Spec::Expectations::ShouldBase's default message generation. This patch adds diffing of arbitrary objects to this mixin. If the 'target' and 'expected' objects both respond to #inspect (which they probably do because Object does) the diff of their inspect strings is added to the message. The existing behaviour is still default (i.e. diffing of an expected String). Motivation: This behaviour is most useful when the objects being compared pretty print their structure when #inspect'ed. For example, this is the case with ASTs constructed by CAST (http://cast.rubyforge.org/). It's almost useless with Rails models, as their #inspect strings are ugly printed (all on the same line, diff doesn't work so well). ---------------------------------------------------------------------- >Comment By: Lachie Cox (lachie) Date: 2006-10-18 13:39 Message: it seems to break a few specs ---------------------------------------------------------------------- Comment By: Lachie Cox (lachie) Date: 2006-10-18 13:34 Message: here's a snippet for making ActiveRecord::Base#inspect pretty print: require 'pp' class ActiveRecord::Base def inspect PP.pp(self,"") end def pretty_print(q) q.pp_object(self) end end A caveat is that diff will notice the differences between the hex object ids printed: -# Patches item #6207, was opened at 2006-10-18 12:32 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6207&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Lachie Cox (lachie) Assigned to: Nobody (None) Summary: Allows --diff option to diff target and expected's #inspect output Initial Comment: The --diff option mixes in unified diffing to Spec::Expectations::ShouldBase's default message generation. This patch adds diffing of arbitrary objects to this mixin. If the 'target' and 'expected' objects both respond to #inspect (which they probably do because Object does) the diff of their inspect strings is added to the message. The existing behaviour is still default (i.e. diffing of an expected String). Motivation: This behaviour is most useful when the objects being compared pretty print their structure when #inspect'ed. For example, this is the case with ASTs constructed by CAST (http://cast.rubyforge.org/). It's almost useless with Rails models, as their #inspect strings are ugly printed (all on the same line, diff doesn't work so well). ---------------------------------------------------------------------- >Comment By: Lachie Cox (lachie) Date: 2006-10-18 13:34 Message: here's a snippet for making ActiveRecord::Base#inspect pretty print: require 'pp' class ActiveRecord::Base def inspect PP.pp(self,"") end def pretty_print(q) q.pp_object(self) end end A caveat is that diff will notice the differences between the hex object ids printed: -# References: <8d961d900610171456i4919c1f0r6b55e3fa4c346cf4@mail.gmail.com> <57c63afe0610172028s3b6799dct362706019627c9ed@mail.gmail.com> Message-ID: <21B3C094-268D-4AC1-A18B-CDF7D690BD37@fastmail.us> On Oct 17, 2006, at 11:28 PM, David Chelimsky wrote: > On 10/17/06, aslak hellesoy wrote: >> For the first time in history RSpec now has 100% coverage. > > That is just ridiculously cool. Congats! Keep up the great work! Craig From brian.takita at gmail.com Wed Oct 18 00:12:43 2006 From: brian.takita at gmail.com (Brian Takita) Date: Tue, 17 Oct 2006 21:12:43 -0700 Subject: [rspec-devel] 100 % In-Reply-To: <57c63afe0610172028s3b6799dct362706019627c9ed@mail.gmail.com> References: <8d961d900610171456i4919c1f0r6b55e3fa4c346cf4@mail.gmail.com> <57c63afe0610172028s3b6799dct362706019627c9ed@mail.gmail.com> Message-ID: <1d7ddd110610172112y22d109bq893ee798c2872f4e@mail.gmail.com> On 10/17/06, David Chelimsky wrote: > > On 10/17/06, aslak hellesoy wrote: > > For the first time in history RSpec now has 100% coverage. > > That is just ridiculously cool. > > Thanks Aslak! Awesome. Good job. > > > Let's keep it that way :-D > > > > Aslak > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061017/64803c56/attachment.html From dastels at daveastels.com Wed Oct 18 02:07:55 2006 From: dastels at daveastels.com (Dave Astels) Date: Wed, 18 Oct 2006 03:07:55 -0300 Subject: [rspec-devel] 100 % In-Reply-To: <8d961d900610171456i4919c1f0r6b55e3fa4c346cf4@mail.gmail.com> References: <8d961d900610171456i4919c1f0r6b55e3fa4c346cf4@mail.gmail.com> Message-ID: <36F50820-0EA1-4EE4-B8BD-25C988BA2F7A@daveastels.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 17-Oct-06, at 6:56 PM, aslak hellesoy wrote: > For the first time in history RSpec now has 100% coverage. All that means is that there is no code that is not executed during the run. It says nothing about the logical coverage. For that we need something like Jester. Is here a ruby version yet? Dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFFNcS7auez/L4x7g4RAvi/AKDGDoZ0Ojkozu1Fq5MXwFQIyAOEWQCgySkX HC8f+/I4u/waFuE4U+8C4gc= =3em2 -----END PGP SIGNATURE----- From dchelimsky at gmail.com Wed Oct 18 06:35:43 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 18 Oct 2006 06:35:43 -0400 Subject: [rspec-devel] 100 % In-Reply-To: <36F50820-0EA1-4EE4-B8BD-25C988BA2F7A@daveastels.com> References: <8d961d900610171456i4919c1f0r6b55e3fa4c346cf4@mail.gmail.com> <36F50820-0EA1-4EE4-B8BD-25C988BA2F7A@daveastels.com> Message-ID: <57c63afe0610180335p2992072bi8298bc1dfbee378d@mail.gmail.com> On 10/18/06, Dave Astels wrote: > On 17-Oct-06, at 6:56 PM, aslak hellesoy wrote: > > > For the first time in history RSpec now has 100% coverage. > > All that means is that there is no code that is not executed during > the run. It says nothing about the logical coverage. Party pooper. > For that we > need something like Jester. Is here a ruby version yet? Hmmm - can anybody say RSpec-2.0? From noreply at rubyforge.org Wed Oct 18 08:28:17 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 18 Oct 2006 08:28:17 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-6053 ] RSpec with Rails: skip_before_filter is ignored on edge rails Message-ID: <20061018122817.920D5A97001F@rubyforge.org> Bugs item #6053, was opened at 2006-10-07 08:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6053&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: RSpec with Rails: skip_before_filter is ignored on edge rails Initial Comment: RSpec on Rails ignores skip_before_filter declarations in controllers being tested with RSpec. Appears to be non-issue with Rails 1.1.6. Broken on edge rails. Example code: # application.rb: class ApplicationController < ActionController::Base before_filter :raise_error def raise_error raise "This should never be called" end end # example_controller.rb class ExampleController < ApplicationController skip_before_filter :raise_error def tester render :text => 'hello world' end end # example_controller_spec.rb => raises error require File.dirname(__FILE__) + '/../spec_helper' context "The ExampleController" do controller_name :example specify "Should skip before_filter :raise_error" do get :tester response.should_be_success end end # example_controller_spec.rb => reports success require File.dirname(__FILE__) + '/../test_helper' require 'example_controller' # Re-raise errors caught by the controller. class ExampleController; def rescue_action(e) raise e end; end class ExampleControllerTest < Test::Unit::TestCase def setup @controller = ExampleController.new @request = ActionController::TestRequest.new @response = ActionController::TestResponse.new end # Replace this with your real tests. def test_no_error_without_rspec get :tester assert_response :success end end ---------------------------------------------------------------------- Comment By: Mike Vincent (agile) Date: 2006-10-18 07:28 Message: I think this is related to http://dev.rubyonrails.org/ticket/5949 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6053&group_id=797 From noreply at rubyforge.org Wed Oct 18 19:32:52 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 18 Oct 2006 19:32:52 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-6207 ] Allows --diff option to diff target and expected's #inspect output Message-ID: <20061018233252.6A64F5241744@rubyforge.org> Patches item #6207, was opened at 2006-10-18 12:32 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6207&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Lachie Cox (lachie) Assigned to: Nobody (None) Summary: Allows --diff option to diff target and expected's #inspect output Initial Comment: The --diff option mixes in unified diffing to Spec::Expectations::ShouldBase's default message generation. This patch adds diffing of arbitrary objects to this mixin. If the 'target' and 'expected' objects both respond to #inspect (which they probably do because Object does) the diff of their inspect strings is added to the message. The existing behaviour is still default (i.e. diffing of an expected String). Motivation: This behaviour is most useful when the objects being compared pretty print their structure when #inspect'ed. For example, this is the case with ASTs constructed by CAST (http://cast.rubyforge.org/). It's almost useless with Rails models, as their #inspect strings are ugly printed (all on the same line, diff doesn't work so well). ---------------------------------------------------------------------- >Comment By: Lachie Cox (lachie) Date: 2006-10-19 09:32 Message: Here is the patch, now with pretty-printing and spec! The method alias-hook (#default_message) of the existing behaviour has no spec. Its covered in an rcov sense because the --diff option is on in the dogfood specs. This is also why the patch breaks 7 existing dogfood specs -- failed message output under --diff is changed by the patch. I'm not sure how to handle that. ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-19 05:15 Message: Looks like the patch didn't get attached. The Rubyforge UI tries to fool you (it happened to me too). Try to attach the patch again - with specs please. ---------------------------------------------------------------------- Comment By: Lachie Cox (lachie) Date: 2006-10-18 13:39 Message: it seems to break a few specs ---------------------------------------------------------------------- Comment By: Lachie Cox (lachie) Date: 2006-10-18 13:34 Message: here's a snippet for making ActiveRecord::Base#inspect pretty print: require 'pp' class ActiveRecord::Base def inspect PP.pp(self,"") end def pretty_print(q) q.pp_object(self) end end A caveat is that diff will notice the differences between the hex object ids printed: -# Patches item #6207, was opened at 2006-10-17 22:32 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6207&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Lachie Cox (lachie) Assigned to: Nobody (None) Summary: Allows --diff option to diff target and expected's #inspect output Initial Comment: The --diff option mixes in unified diffing to Spec::Expectations::ShouldBase's default message generation. This patch adds diffing of arbitrary objects to this mixin. If the 'target' and 'expected' objects both respond to #inspect (which they probably do because Object does) the diff of their inspect strings is added to the message. The existing behaviour is still default (i.e. diffing of an expected String). Motivation: This behaviour is most useful when the objects being compared pretty print their structure when #inspect'ed. For example, this is the case with ASTs constructed by CAST (http://cast.rubyforge.org/). It's almost useless with Rails models, as their #inspect strings are ugly printed (all on the same line, diff doesn't work so well). ---------------------------------------------------------------------- >Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-18 15:15 Message: Looks like the patch didn't get attached. The Rubyforge UI tries to fool you (it happened to me too). Try to attach the patch again - with specs please. ---------------------------------------------------------------------- Comment By: Lachie Cox (lachie) Date: 2006-10-17 23:39 Message: it seems to break a few specs ---------------------------------------------------------------------- Comment By: Lachie Cox (lachie) Date: 2006-10-17 23:34 Message: here's a snippet for making ActiveRecord::Base#inspect pretty print: require 'pp' class ActiveRecord::Base def inspect PP.pp(self,"") end def pretty_print(q) q.pp_object(self) end end A caveat is that diff will notice the differences between the hex object ids printed: -# Feature Requests item #6233, was opened at 2006-10-19 06:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6233&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Aslak Hellesoy (aslak_hellesoy) Assigned to: Nobody (None) Summary: Colours in specdoc Initial Comment: I'd like to colours if I run with --format specdoc --colour Foo - this is red - this is green etc. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6233&group_id=797 From noreply at rubyforge.org Thu Oct 19 06:27:53 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 19 Oct 2006 06:27:53 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-6207 ] Allows --diff option to diff target and expected's #inspect output Message-ID: <20061019102753.40D4552411C9@rubyforge.org> Patches item #6207, was opened at 2006-10-17 22:32 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6207&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Lachie Cox (lachie) Assigned to: Nobody (None) Summary: Allows --diff option to diff target and expected's #inspect output Initial Comment: The --diff option mixes in unified diffing to Spec::Expectations::ShouldBase's default message generation. This patch adds diffing of arbitrary objects to this mixin. If the 'target' and 'expected' objects both respond to #inspect (which they probably do because Object does) the diff of their inspect strings is added to the message. The existing behaviour is still default (i.e. diffing of an expected String). Motivation: This behaviour is most useful when the objects being compared pretty print their structure when #inspect'ed. For example, this is the case with ASTs constructed by CAST (http://cast.rubyforge.org/). It's almost useless with Rails models, as their #inspect strings are ugly printed (all on the same line, diff doesn't work so well). ---------------------------------------------------------------------- >Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-19 06:27 Message: Would it make sense to just update those failing specs so that they reflect the new diffing behaviour? ---------------------------------------------------------------------- Comment By: Lachie Cox (lachie) Date: 2006-10-18 19:32 Message: Here is the patch, now with pretty-printing and spec! The method alias-hook (#default_message) of the existing behaviour has no spec. Its covered in an rcov sense because the --diff option is on in the dogfood specs. This is also why the patch breaks 7 existing dogfood specs -- failed message output under --diff is changed by the patch. I'm not sure how to handle that. ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-18 15:15 Message: Looks like the patch didn't get attached. The Rubyforge UI tries to fool you (it happened to me too). Try to attach the patch again - with specs please. ---------------------------------------------------------------------- Comment By: Lachie Cox (lachie) Date: 2006-10-17 23:39 Message: it seems to break a few specs ---------------------------------------------------------------------- Comment By: Lachie Cox (lachie) Date: 2006-10-17 23:34 Message: here's a snippet for making ActiveRecord::Base#inspect pretty print: require 'pp' class ActiveRecord::Base def inspect PP.pp(self,"") end def pretty_print(q) q.pp_object(self) end end A caveat is that diff will notice the differences between the hex object ids printed: -# Patches item #6207, was opened at 2006-10-17 22:32 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6207&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Lachie Cox (lachie) Assigned to: Nobody (None) Summary: Allows --diff option to diff target and expected's #inspect output Initial Comment: The --diff option mixes in unified diffing to Spec::Expectations::ShouldBase's default message generation. This patch adds diffing of arbitrary objects to this mixin. If the 'target' and 'expected' objects both respond to #inspect (which they probably do because Object does) the diff of their inspect strings is added to the message. The existing behaviour is still default (i.e. diffing of an expected String). Motivation: This behaviour is most useful when the objects being compared pretty print their structure when #inspect'ed. For example, this is the case with ASTs constructed by CAST (http://cast.rubyforge.org/). It's almost useless with Rails models, as their #inspect strings are ugly printed (all on the same line, diff doesn't work so well). ---------------------------------------------------------------------- >Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-19 18:27 Message: The patch doesn't apply to HEAD of trunk. Further, the "should output unified diff message of two objects" spec assumes a particular PP rendering of the hash - which to my judgement is non-deterministic (the ordering of the key/value pairs). It would be better to use something that PP renders more deterministically - perhaps we ought to use a particular class in the spec with custom deterministic (multiline) PP rendering. Can you fix that? ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-19 12:43 Message: Yes, please add a full patch with updated specs. I'll review it and try to get it in for 0.7. I love the idea! ---------------------------------------------------------------------- Comment By: Lachie Cox (lachie) Date: 2006-10-19 09:01 Message: Yes, if we think the patched behaviour is desirable and correct. Should I add a patch to update the failing specs? ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-19 06:27 Message: Would it make sense to just update those failing specs so that they reflect the new diffing behaviour? ---------------------------------------------------------------------- Comment By: Lachie Cox (lachie) Date: 2006-10-18 19:32 Message: Here is the patch, now with pretty-printing and spec! The method alias-hook (#default_message) of the existing behaviour has no spec. Its covered in an rcov sense because the --diff option is on in the dogfood specs. This is also why the patch breaks 7 existing dogfood specs -- failed message output under --diff is changed by the patch. I'm not sure how to handle that. ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-18 15:15 Message: Looks like the patch didn't get attached. The Rubyforge UI tries to fool you (it happened to me too). Try to attach the patch again - with specs please. ---------------------------------------------------------------------- Comment By: Lachie Cox (lachie) Date: 2006-10-17 23:39 Message: it seems to break a few specs ---------------------------------------------------------------------- Comment By: Lachie Cox (lachie) Date: 2006-10-17 23:34 Message: here's a snippet for making ActiveRecord::Base#inspect pretty print: require 'pp' class ActiveRecord::Base def inspect PP.pp(self,"") end def pretty_print(q) q.pp_object(self) end end A caveat is that diff will notice the differences between the hex object ids printed: -# Patches item #6207, was opened at 2006-10-17 22:32 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6207&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Lachie Cox (lachie) Assigned to: Nobody (None) Summary: Allows --diff option to diff target and expected's #inspect output Initial Comment: The --diff option mixes in unified diffing to Spec::Expectations::ShouldBase's default message generation. This patch adds diffing of arbitrary objects to this mixin. If the 'target' and 'expected' objects both respond to #inspect (which they probably do because Object does) the diff of their inspect strings is added to the message. The existing behaviour is still default (i.e. diffing of an expected String). Motivation: This behaviour is most useful when the objects being compared pretty print their structure when #inspect'ed. For example, this is the case with ASTs constructed by CAST (http://cast.rubyforge.org/). It's almost useless with Rails models, as their #inspect strings are ugly printed (all on the same line, diff doesn't work so well). ---------------------------------------------------------------------- >Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-19 12:43 Message: Yes, please add a full patch with updated specs. I'll review it and try to get it in for 0.7. I love the idea! ---------------------------------------------------------------------- Comment By: Lachie Cox (lachie) Date: 2006-10-19 09:01 Message: Yes, if we think the patched behaviour is desirable and correct. Should I add a patch to update the failing specs? ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-19 06:27 Message: Would it make sense to just update those failing specs so that they reflect the new diffing behaviour? ---------------------------------------------------------------------- Comment By: Lachie Cox (lachie) Date: 2006-10-18 19:32 Message: Here is the patch, now with pretty-printing and spec! The method alias-hook (#default_message) of the existing behaviour has no spec. Its covered in an rcov sense because the --diff option is on in the dogfood specs. This is also why the patch breaks 7 existing dogfood specs -- failed message output under --diff is changed by the patch. I'm not sure how to handle that. ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-18 15:15 Message: Looks like the patch didn't get attached. The Rubyforge UI tries to fool you (it happened to me too). Try to attach the patch again - with specs please. ---------------------------------------------------------------------- Comment By: Lachie Cox (lachie) Date: 2006-10-17 23:39 Message: it seems to break a few specs ---------------------------------------------------------------------- Comment By: Lachie Cox (lachie) Date: 2006-10-17 23:34 Message: here's a snippet for making ActiveRecord::Base#inspect pretty print: require 'pp' class ActiveRecord::Base def inspect PP.pp(self,"") end def pretty_print(q) q.pp_object(self) end end A caveat is that diff will notice the differences between the hex object ids printed: -# Patches item #6207, was opened at 2006-10-18 12:32 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6207&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Lachie Cox (lachie) Assigned to: Nobody (None) Summary: Allows --diff option to diff target and expected's #inspect output Initial Comment: The --diff option mixes in unified diffing to Spec::Expectations::ShouldBase's default message generation. This patch adds diffing of arbitrary objects to this mixin. If the 'target' and 'expected' objects both respond to #inspect (which they probably do because Object does) the diff of their inspect strings is added to the message. The existing behaviour is still default (i.e. diffing of an expected String). Motivation: This behaviour is most useful when the objects being compared pretty print their structure when #inspect'ed. For example, this is the case with ASTs constructed by CAST (http://cast.rubyforge.org/). It's almost useless with Rails models, as their #inspect strings are ugly printed (all on the same line, diff doesn't work so well). ---------------------------------------------------------------------- >Comment By: Lachie Cox (lachie) Date: 2006-10-19 23:01 Message: Yes, if we think the patched behaviour is desirable and correct. Should I add a patch to update the failing specs? ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-19 20:27 Message: Would it make sense to just update those failing specs so that they reflect the new diffing behaviour? ---------------------------------------------------------------------- Comment By: Lachie Cox (lachie) Date: 2006-10-19 09:32 Message: Here is the patch, now with pretty-printing and spec! The method alias-hook (#default_message) of the existing behaviour has no spec. Its covered in an rcov sense because the --diff option is on in the dogfood specs. This is also why the patch breaks 7 existing dogfood specs -- failed message output under --diff is changed by the patch. I'm not sure how to handle that. ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-19 05:15 Message: Looks like the patch didn't get attached. The Rubyforge UI tries to fool you (it happened to me too). Try to attach the patch again - with specs please. ---------------------------------------------------------------------- Comment By: Lachie Cox (lachie) Date: 2006-10-18 13:39 Message: it seems to break a few specs ---------------------------------------------------------------------- Comment By: Lachie Cox (lachie) Date: 2006-10-18 13:34 Message: here's a snippet for making ActiveRecord::Base#inspect pretty print: require 'pp' class ActiveRecord::Base def inspect PP.pp(self,"") end def pretty_print(q) q.pp_object(self) end end A caveat is that diff will notice the differences between the hex object ids printed: -# Just browsing http://rspec.rubyforge.org/tools/spec.html and thought I noticed a typo in the "--color" option: "-s,?color,?colour Show coloured (red/green) output." I think that should be "-c,--color,--colour", right? Also, in all of the examples, "--" appears as "?", which might be confusing... Cheers! Eric Watson From dchelimsky at gmail.com Thu Oct 19 19:31:03 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 19 Oct 2006 19:31:03 -0400 Subject: [rspec-devel] typo on spec documentation page In-Reply-To: <4C840871-A08C-409F-A013-ABFC86B7291E@brownline.net> References: <4C840871-A08C-409F-A013-ABFC86B7291E@brownline.net> Message-ID: <57c63afe0610191631v517b9120nac3a43b19f216e7c@mail.gmail.com> On 10/19/06, Eric Watson wrote: > Just browsing > > http://rspec.rubyforge.org/tools/spec.html > > and thought I noticed a typo in the "--color" option: > > "-s,?color,?colour > Show coloured (red/green) output." > > I think that should be "-c,--color,--colour", right? > Also, in all of the examples, "--" appears as "?", which might be > confusing... Thanks. This is fixed in the trunk and will be correct when we release (soon). And yes, we do need to think about the font we are using there. It is confusing. Thanks. David > > Cheers! > > Eric Watson > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From aslak.hellesoy at gmail.com Sat Oct 21 07:10:03 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sat, 21 Oct 2006 13:10:03 +0200 Subject: [rspec-devel] --diff broken on trunk Message-ID: <8d961d900610210410w13bc60f1j1fdbb68634cf916e@mail.gmail.com> http://rubyforge.org/tracker/index.php?func=detail&aid=6259&group_id=797&atid=3149 This is a regression that has been introduced some time since last release, and it must be fixed before we make a new release. This is apparently not verified, and we need to amend our specs. When it's fixed (I'm not sure what it is yet) I think we should apply Lachie's Object diff patch: http://rubyforge.org/tracker/index.php?func=detail&aid=6207&group_id=797&atid=3151 From aslak.hellesoy at gmail.com Sat Oct 21 09:41:35 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sat, 21 Oct 2006 15:41:35 +0200 Subject: [rspec-devel] --diff broken on trunk In-Reply-To: <8d961d900610210410w13bc60f1j1fdbb68634cf916e@mail.gmail.com> References: <8d961d900610210410w13bc60f1j1fdbb68634cf916e@mail.gmail.com> Message-ID: <8d961d900610210641v1967fa47icc75adfccf0aa24b@mail.gmail.com> On 10/21/06, aslak hellesoy wrote: > http://rubyforge.org/tracker/index.php?func=detail&aid=6259&group_id=797&atid=3149 > > This is a regression that has been introduced some time since last > release, and it must be fixed before we make a new release. This is > apparently not verified, and we need to amend our specs. > Ok, I just fixed this. > When it's fixed (I'm not sure what it is yet) I think we should apply > Lachie's Object diff patch: > http://rubyforge.org/tracker/index.php?func=detail&aid=6207&group_id=797&atid=3151 > And applied this one too. Aslak From noreply at rubyforge.org Sat Oct 21 01:44:22 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 21 Oct 2006 01:44:22 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-6207 ] Allows --diff option to diff target and expected's #inspect output Message-ID: <20061021054422.122B15240AE3@rubyforge.org> Patches item #6207, was opened at 2006-10-18 12:32 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6207&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Lachie Cox (lachie) Assigned to: Nobody (None) Summary: Allows --diff option to diff target and expected's #inspect output Initial Comment: The --diff option mixes in unified diffing to Spec::Expectations::ShouldBase's default message generation. This patch adds diffing of arbitrary objects to this mixin. If the 'target' and 'expected' objects both respond to #inspect (which they probably do because Object does) the diff of their inspect strings is added to the message. The existing behaviour is still default (i.e. diffing of an expected String). Motivation: This behaviour is most useful when the objects being compared pretty print their structure when #inspect'ed. For example, this is the case with ASTs constructed by CAST (http://cast.rubyforge.org/). It's almost useless with Rails models, as their #inspect strings are ugly printed (all on the same line, diff doesn't work so well). ---------------------------------------------------------------------- >Comment By: Lachie Cox (lachie) Date: 2006-10-21 15:44 Message: OK, I found both those problems too and fixed them. No diffing takes place if expected == :no_expectation_specified allowing unary expectations to give messages as expected. I'm looking at the output wrt lambdas and raising, for example in "should_not_raise should fail when specific exception is raised". The patch now skips diffing if target is a Proc. I don't think diffing makes sense in this case, as the message output is more diagnostic of the failure of the example than descriptive of its subjects -- the lambda Proc isn't really the subject of the example. After excepting Procs, there was only one example to update "Mock should fail if expectation block fails" ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-20 08:27 Message: The patch doesn't apply to HEAD of trunk. Further, the "should output unified diff message of two objects" spec assumes a particular PP rendering of the hash - which to my judgement is non-deterministic (the ordering of the key/value pairs). It would be better to use something that PP renders more deterministically - perhaps we ought to use a particular class in the spec with custom deterministic (multiline) PP rendering. Can you fix that? ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-20 02:43 Message: Yes, please add a full patch with updated specs. I'll review it and try to get it in for 0.7. I love the idea! ---------------------------------------------------------------------- Comment By: Lachie Cox (lachie) Date: 2006-10-19 23:01 Message: Yes, if we think the patched behaviour is desirable and correct. Should I add a patch to update the failing specs? ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-19 20:27 Message: Would it make sense to just update those failing specs so that they reflect the new diffing behaviour? ---------------------------------------------------------------------- Comment By: Lachie Cox (lachie) Date: 2006-10-19 09:32 Message: Here is the patch, now with pretty-printing and spec! The method alias-hook (#default_message) of the existing behaviour has no spec. Its covered in an rcov sense because the --diff option is on in the dogfood specs. This is also why the patch breaks 7 existing dogfood specs -- failed message output under --diff is changed by the patch. I'm not sure how to handle that. ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-19 05:15 Message: Looks like the patch didn't get attached. The Rubyforge UI tries to fool you (it happened to me too). Try to attach the patch again - with specs please. ---------------------------------------------------------------------- Comment By: Lachie Cox (lachie) Date: 2006-10-18 13:39 Message: it seems to break a few specs ---------------------------------------------------------------------- Comment By: Lachie Cox (lachie) Date: 2006-10-18 13:34 Message: here's a snippet for making ActiveRecord::Base#inspect pretty print: require 'pp' class ActiveRecord::Base def inspect PP.pp(self,"") end def pretty_print(q) q.pp_object(self) end end A caveat is that diff will notice the differences between the hex object ids printed: -# Bugs item #6259, was opened at 2006-10-21 07:05 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6259&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Aslak Hellesoy (aslak_hellesoy) Assigned to: Nobody (None) Summary: --diff broken on trunk Initial Comment: Try the following on trunk: ruby -Ilib bin/spec failing_examples/big_string_spec.rb --diff The diff is not printed to stdout. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6259&group_id=797 From noreply at rubyforge.org Sat Oct 21 09:16:14 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 21 Oct 2006 09:16:14 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-6259 ] --diff broken on trunk Message-ID: <20061021131614.9651A5241C64@rubyforge.org> Bugs item #6259, was opened at 2006-10-21 07:05 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6259&group_id=797 Category: None Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Aslak Hellesoy (aslak_hellesoy) >Assigned to: Aslak Hellesoy (aslak_hellesoy) Summary: --diff broken on trunk Initial Comment: Try the following on trunk: ruby -Ilib bin/spec failing_examples/big_string_spec.rb --diff The diff is not printed to stdout. ---------------------------------------------------------------------- >Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-21 09:16 Message: Fixed! ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6259&group_id=797 From noreply at rubyforge.org Sat Oct 21 01:46:09 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 21 Oct 2006 01:46:09 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-6207 ] Allows --diff option to diff target and expected's #inspect output Message-ID: <20061021054612.31C105240B1A@rubyforge.org> Patches item #6207, was opened at 2006-10-18 12:32 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6207&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Lachie Cox (lachie) Assigned to: Nobody (None) Summary: Allows --diff option to diff target and expected's #inspect output Initial Comment: The --diff option mixes in unified diffing to Spec::Expectations::ShouldBase's default message generation. This patch adds diffing of arbitrary objects to this mixin. If the 'target' and 'expected' objects both respond to #inspect (which they probably do because Object does) the diff of their inspect strings is added to the message. The existing behaviour is still default (i.e. diffing of an expected String). Motivation: This behaviour is most useful when the objects being compared pretty print their structure when #inspect'ed. For example, this is the case with ASTs constructed by CAST (http://cast.rubyforge.org/). It's almost useless with Rails models, as their #inspect strings are ugly printed (all on the same line, diff doesn't work so well). ---------------------------------------------------------------------- >Comment By: Lachie Cox (lachie) Date: 2006-10-21 15:46 Message: sorry, forgot to add a description to the latest version of the patch ---------------------------------------------------------------------- Comment By: Lachie Cox (lachie) Date: 2006-10-21 15:44 Message: OK, I found both those problems too and fixed them. No diffing takes place if expected == :no_expectation_specified allowing unary expectations to give messages as expected. I'm looking at the output wrt lambdas and raising, for example in "should_not_raise should fail when specific exception is raised". The patch now skips diffing if target is a Proc. I don't think diffing makes sense in this case, as the message output is more diagnostic of the failure of the example than descriptive of its subjects -- the lambda Proc isn't really the subject of the example. After excepting Procs, there was only one example to update "Mock should fail if expectation block fails" ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-20 08:27 Message: The patch doesn't apply to HEAD of trunk. Further, the "should output unified diff message of two objects" spec assumes a particular PP rendering of the hash - which to my judgement is non-deterministic (the ordering of the key/value pairs). It would be better to use something that PP renders more deterministically - perhaps we ought to use a particular class in the spec with custom deterministic (multiline) PP rendering. Can you fix that? ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-20 02:43 Message: Yes, please add a full patch with updated specs. I'll review it and try to get it in for 0.7. I love the idea! ---------------------------------------------------------------------- Comment By: Lachie Cox (lachie) Date: 2006-10-19 23:01 Message: Yes, if we think the patched behaviour is desirable and correct. Should I add a patch to update the failing specs? ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-19 20:27 Message: Would it make sense to just update those failing specs so that they reflect the new diffing behaviour? ---------------------------------------------------------------------- Comment By: Lachie Cox (lachie) Date: 2006-10-19 09:32 Message: Here is the patch, now with pretty-printing and spec! The method alias-hook (#default_message) of the existing behaviour has no spec. Its covered in an rcov sense because the --diff option is on in the dogfood specs. This is also why the patch breaks 7 existing dogfood specs -- failed message output under --diff is changed by the patch. I'm not sure how to handle that. ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-19 05:15 Message: Looks like the patch didn't get attached. The Rubyforge UI tries to fool you (it happened to me too). Try to attach the patch again - with specs please. ---------------------------------------------------------------------- Comment By: Lachie Cox (lachie) Date: 2006-10-18 13:39 Message: it seems to break a few specs ---------------------------------------------------------------------- Comment By: Lachie Cox (lachie) Date: 2006-10-18 13:34 Message: here's a snippet for making ActiveRecord::Base#inspect pretty print: require 'pp' class ActiveRecord::Base def inspect PP.pp(self,"") end def pretty_print(q) q.pp_object(self) end end A caveat is that diff will notice the differences between the hex object ids printed: -# Patches item #6207, was opened at 2006-10-17 22:32 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6207&group_id=797 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Lachie Cox (lachie) >Assigned to: Aslak Hellesoy (aslak_hellesoy) Summary: Allows --diff option to diff target and expected's #inspect output Initial Comment: The --diff option mixes in unified diffing to Spec::Expectations::ShouldBase's default message generation. This patch adds diffing of arbitrary objects to this mixin. If the 'target' and 'expected' objects both respond to #inspect (which they probably do because Object does) the diff of their inspect strings is added to the message. The existing behaviour is still default (i.e. diffing of an expected String). Motivation: This behaviour is most useful when the objects being compared pretty print their structure when #inspect'ed. For example, this is the case with ASTs constructed by CAST (http://cast.rubyforge.org/). It's almost useless with Rails models, as their #inspect strings are ugly printed (all on the same line, diff doesn't work so well). ---------------------------------------------------------------------- >Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-21 09:38 Message: Applied. Will be in 0.7.0 ---------------------------------------------------------------------- Comment By: Lachie Cox (lachie) Date: 2006-10-21 01:46 Message: sorry, forgot to add a description to the latest version of the patch ---------------------------------------------------------------------- Comment By: Lachie Cox (lachie) Date: 2006-10-21 01:44 Message: OK, I found both those problems too and fixed them. No diffing takes place if expected == :no_expectation_specified allowing unary expectations to give messages as expected. I'm looking at the output wrt lambdas and raising, for example in "should_not_raise should fail when specific exception is raised". The patch now skips diffing if target is a Proc. I don't think diffing makes sense in this case, as the message output is more diagnostic of the failure of the example than descriptive of its subjects -- the lambda Proc isn't really the subject of the example. After excepting Procs, there was only one example to update "Mock should fail if expectation block fails" ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-19 18:27 Message: The patch doesn't apply to HEAD of trunk. Further, the "should output unified diff message of two objects" spec assumes a particular PP rendering of the hash - which to my judgement is non-deterministic (the ordering of the key/value pairs). It would be better to use something that PP renders more deterministically - perhaps we ought to use a particular class in the spec with custom deterministic (multiline) PP rendering. Can you fix that? ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-19 12:43 Message: Yes, please add a full patch with updated specs. I'll review it and try to get it in for 0.7. I love the idea! ---------------------------------------------------------------------- Comment By: Lachie Cox (lachie) Date: 2006-10-19 09:01 Message: Yes, if we think the patched behaviour is desirable and correct. Should I add a patch to update the failing specs? ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-19 06:27 Message: Would it make sense to just update those failing specs so that they reflect the new diffing behaviour? ---------------------------------------------------------------------- Comment By: Lachie Cox (lachie) Date: 2006-10-18 19:32 Message: Here is the patch, now with pretty-printing and spec! The method alias-hook (#default_message) of the existing behaviour has no spec. Its covered in an rcov sense because the --diff option is on in the dogfood specs. This is also why the patch breaks 7 existing dogfood specs -- failed message output under --diff is changed by the patch. I'm not sure how to handle that. ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-18 15:15 Message: Looks like the patch didn't get attached. The Rubyforge UI tries to fool you (it happened to me too). Try to attach the patch again - with specs please. ---------------------------------------------------------------------- Comment By: Lachie Cox (lachie) Date: 2006-10-17 23:39 Message: it seems to break a few specs ---------------------------------------------------------------------- Comment By: Lachie Cox (lachie) Date: 2006-10-17 23:34 Message: here's a snippet for making ActiveRecord::Base#inspect pretty print: require 'pp' class ActiveRecord::Base def inspect PP.pp(self,"") end def pretty_print(q) q.pp_object(self) end end A caveat is that diff will notice the differences between the hex object ids printed: -# Feature Requests item #6233, was opened at 2006-10-19 06:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6233&group_id=797 Category: None Group: None >Status: Closed Priority: 3 Submitted By: Aslak Hellesoy (aslak_hellesoy) >Assigned to: Aslak Hellesoy (aslak_hellesoy) Summary: Colours in specdoc Initial Comment: I'd like to colours if I run with --format specdoc --colour Foo - this is red - this is green etc. ---------------------------------------------------------------------- >Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-21 09:39 Message: Fixed. Will be in 0.7.0 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6233&group_id=797 From noreply at rubyforge.org Sat Oct 21 10:37:33 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 21 Oct 2006 10:37:33 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-6056 ] Multiple output of failing-spec notice Message-ID: <20061021143733.F27705241C8A@rubyforge.org> Bugs item #6056, was opened at 2006-10-07 17:33 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6056&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Sam Livingston-Gray (geeksam) Assigned to: Nobody (None) Summary: Multiple output of failing-spec notice Initial Comment: Using RSpec 0.6.4, running the following specs: context 'A failing context' do specify 'should fail' do true.should_be false end end context 'A different context just minding its own business' do specify 'should pass' do true.should_be true end end Produces this output: F 1) Spec::Expectations::ExpectationNotMetError in 'A failing context should fail' true should be false rspec_bug.rb:7:in `should fail' rspec_bug.rb:5 Finished in 0.015 seconds 1 specification, 1 failure F. 1) Spec::Expectations::ExpectationNotMetError in 'A failing context should fail' true should be false rspec_bug.rb:7:in `should fail' rspec_bug.rb:5 2) Spec::Expectations::ExpectationNotMetError in 'A failing context should fail' true should be false rspec_bug.rb:7:in `should fail' rspec_bug.rb:17 Finished in 0.0 seconds 3 specifications, 2 failures ---------------------------------------------------------------------- >Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-21 10:37 Message: Fixed. Will be in 0.7.0 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6056&group_id=797 From noreply at rubyforge.org Sat Oct 21 10:20:17 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 21 Oct 2006 10:20:17 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-6094 ] rspec_on_rails pre-commit fails w/ -b option turned off Message-ID: <20061021142019.097CA5241C77@rubyforge.org> Bugs item #6094, was opened at 2006-10-11 00:45 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6094&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: rspec_on_rails pre-commit fails w/ -b option turned off Initial Comment: This is in the trunk as of revision 868. Go to ~/vendor/rspec_on_rails/lib/tasks/bootstrap_rspec.rake and remove or comment the line that reads: t.spec_opts = ['-b'] Stand in ~/vendor/rspec_on-rails and execute: ../../bin/spec spec ../../bin/spec specs Everything should pass Now try this: rake pre_commit You'll get the following error (or similar): 1) NoMethodError in 'Given an rjs call to insert html in a div, a 'should_not_have_rjs' spec with no text but wrong element name should pass' You have a nil object when you didn't expect it! You might have expected an instance of Array. The error occured while evaluating nil.size generated_code/routing/generation.rb:30:in `generate_default_path' ./specs/should_not_have_rjs_spec.rb:99:in `setup' /Users/david/projects/ruby/rspec-all/trunk/vendor/rspec_on_rails/vendor/plugins/rspec/lib/extensions/spec/runner/context.rb:30:in `run' ---------------------------------------------------------------------- >Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-21 10:20 Message: I cannot reproduce this on trunk. Does this still apply? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6094&group_id=797 From noreply at rubyforge.org Sat Oct 21 10:34:49 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 21 Oct 2006 10:34:49 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-5564 ] "ruby spec_file.rb" doesn't work the same way as "spec spec_file.rb" Message-ID: <20061021143449.486D95241084@rubyforge.org> Bugs item #5564, was opened at 2006-08-29 21:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=5564&group_id=797 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: David Chelimsky (dchelimsky) >Assigned to: Aslak Hellesoy (aslak_hellesoy) >Summary: "ruby spec_file.rb" doesn't work the same way as "spec spec_file.rb" Initial Comment: Given the following spec file: ============================= require 'spec' context 'first context' do specify 'first spec' do end specify 'second spec' do end end context 'second context' do specify 'third spec' do end specify 'fourth spec' do end specify 'fifth spec' do end end ============================= Running the spec command we get the following output: ============================= $ spec sample_spec.rb -fs first context - first spec - second spec second context - third spec - fourth spec - fifth spec Finished in 0.00197 seconds 5 specifications, 0 failures ============================= Running the ruby command we get the following output: ============================= $ ruby sample_spec.rb -fs first context - first spec - second spec Finished in 0.000794 seconds 2 specifications, 0 failures first context - first spec - second spec second context - third spec - fourth spec - fifth spec Finished in 0.001769 seconds 7 specifications, 0 failures ---------------------------------------------------------------------- >Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-21 10:34 Message: Fixed. Will be in 0.7.0 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=5564&group_id=797 From noreply at rubyforge.org Sat Oct 21 10:37:53 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 21 Oct 2006 10:37:53 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-6056 ] Multiple output of failing-spec notice Message-ID: <20061021143753.AC9575241C87@rubyforge.org> Bugs item #6056, was opened at 2006-10-07 17:33 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6056&group_id=797 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Sam Livingston-Gray (geeksam) >Assigned to: Aslak Hellesoy (aslak_hellesoy) Summary: Multiple output of failing-spec notice Initial Comment: Using RSpec 0.6.4, running the following specs: context 'A failing context' do specify 'should fail' do true.should_be false end end context 'A different context just minding its own business' do specify 'should pass' do true.should_be true end end Produces this output: F 1) Spec::Expectations::ExpectationNotMetError in 'A failing context should fail' true should be false rspec_bug.rb:7:in `should fail' rspec_bug.rb:5 Finished in 0.015 seconds 1 specification, 1 failure F. 1) Spec::Expectations::ExpectationNotMetError in 'A failing context should fail' true should be false rspec_bug.rb:7:in `should fail' rspec_bug.rb:5 2) Spec::Expectations::ExpectationNotMetError in 'A failing context should fail' true should be false rspec_bug.rb:7:in `should fail' rspec_bug.rb:17 Finished in 0.0 seconds 3 specifications, 2 failures ---------------------------------------------------------------------- >Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-21 10:37 Message: Fixed. Will be in 0.7.0 ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-21 10:37 Message: Fixed. Will be in 0.7.0 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6056&group_id=797 From noreply at rubyforge.org Sun Oct 22 01:46:25 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 22 Oct 2006 01:46:25 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-6265 ] should_raise should accept an Exception object Message-ID: <20061022054625.4E5115240A84@rubyforge.org> Feature Requests item #6265, was opened at 2006-10-22 05:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6265&group_id=797 Category: mock module Group: None Status: Open Priority: 3 Submitted By: Chad Woolley (thewoolleyman) Assigned to: Nobody (None) Summary: should_raise should accept an Exception object Initial Comment: So I can pass it an exception object with the message (or anything else) set on it. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6265&group_id=797 From noreply at rubyforge.org Sun Oct 22 01:59:10 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 22 Oct 2006 01:59:10 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-6266 ] Failures with Sqlite3 as test DB with rails Message-ID: <20061022055910.E45805240AA1@rubyforge.org> Bugs item #6266, was opened at 2006-10-22 01:59 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6266&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: Failures with Sqlite3 as test DB with rails Initial Comment: $ spec -fs spec/models/ A new paste /opt/local/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.1.0/lib/sqlite3/errors.rb:94:in `check': cannot rollback - no transaction is active (SQLite3::SQLException) from /opt/local/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.1.0/lib/sqlite3/resultset.rb:76:in `check' from /opt/local/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.1.0/lib/sqlite3/resultset.rb:68:in `commence' from /opt/local/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.1.0/lib/sqlite3/resultset.rb:61:in `initialize' from /opt/local/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.1.0/lib/sqlite3/statement.rb:158:in `execute' from /opt/local/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.1.0/lib/sqlite3/database.rb:211:in `execute' from /opt/local/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.1.0/lib/sqlite3/database.rb:186:in `prepare' from /opt/local/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.1.0/lib/sqlite3/database.rb:210:in `execute' from /opt/local/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.1.0/lib/sqlite3/database.rb:620:in `rollback' ... 13 levels... from /opt/local/lib/ruby/gems/1.8/gems/rspec-0.6.4/lib/spec/runner/context_runner.rb:25:in `run' from /opt/local/lib/ruby/gems/1.8/gems/rspec-0.6.4/lib/spec/runner/context_runner.rb:24:in `run' from /opt/local/lib/ruby/gems/1.8/gems/rspec-0.6.4/bin/spec:18 from /opt/local/bin/spec:18 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6266&group_id=797 From noreply at rubyforge.org Sun Oct 22 08:28:49 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 22 Oct 2006 08:28:49 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-6266 ] Failures with Sqlite3 as test DB with rails Message-ID: <20061022122849.BF7EA5240D6A@rubyforge.org> Bugs item #6266, was opened at 2006-10-22 01:59 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6266&group_id=797 Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: Failures with Sqlite3 as test DB with rails Initial Comment: $ spec -fs spec/models/ A new paste /opt/local/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.1.0/lib/sqlite3/errors.rb:94:in `check': cannot rollback - no transaction is active (SQLite3::SQLException) from /opt/local/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.1.0/lib/sqlite3/resultset.rb:76:in `check' from /opt/local/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.1.0/lib/sqlite3/resultset.rb:68:in `commence' from /opt/local/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.1.0/lib/sqlite3/resultset.rb:61:in `initialize' from /opt/local/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.1.0/lib/sqlite3/statement.rb:158:in `execute' from /opt/local/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.1.0/lib/sqlite3/database.rb:211:in `execute' from /opt/local/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.1.0/lib/sqlite3/database.rb:186:in `prepare' from /opt/local/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.1.0/lib/sqlite3/database.rb:210:in `execute' from /opt/local/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.1.0/lib/sqlite3/database.rb:620:in `rollback' ... 13 levels... from /opt/local/lib/ruby/gems/1.8/gems/rspec-0.6.4/lib/spec/runner/context_runner.rb:25:in `run' from /opt/local/lib/ruby/gems/1.8/gems/rspec-0.6.4/lib/spec/runner/context_runner.rb:24:in `run' from /opt/local/lib/ruby/gems/1.8/gems/rspec-0.6.4/bin/spec:18 from /opt/local/bin/spec:18 ---------------------------------------------------------------------- >Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-22 08:28 Message: That's just too little info to reproduce this behaviour. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6266&group_id=797 From noreply at rubyforge.org Sun Oct 22 08:42:17 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 22 Oct 2006 08:42:17 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-6265 ] should_raise should accept an Exception object Message-ID: <20061022124217.909275240D7E@rubyforge.org> Feature Requests item #6265, was opened at 2006-10-22 01:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6265&group_id=797 Category: mock module Group: None >Status: Closed Priority: 3 Submitted By: Chad Woolley (thewoolleyman) Assigned to: Nobody (None) Summary: should_raise should accept an Exception object Initial Comment: So I can pass it an exception object with the message (or anything else) set on it. ---------------------------------------------------------------------- >Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-22 08:42 Message: I'm a little confused. You categorised this RFE in the mock module. RSpec mocks don't have a sould_raise method, but an and_raise method (which allows you to pass in an exception) http://rspec.rubyforge.org/documentation/mocks.html http://rubyforge.org/cgi-bin/viewvc.cgi/trunk/spec/spec/mocks/mock_spec.rb?revision=931&root=rspec Or perhaps you're talking about the Proc#should_raise method? It also allows you to pass an exception object: http://rubyforge.org/cgi-bin/viewvc.cgi/trunk/spec/spec/expectations/should/should_raise_spec.rb?root=rspec&view=co http://rspec.rubyforge.org/documentation/expectations.html If this doesn't work for you, please submit a failing spec. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6265&group_id=797 From noreply at rubyforge.org Sun Oct 22 15:24:51 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 22 Oct 2006 15:24:51 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-5435 ] mock#and_return should support multiple return values from passed in arguments Message-ID: <20061022192451.4EA365241DE4@rubyforge.org> Feature Requests item #5435, was opened at 2006-08-16 01:53 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5435&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Aslak Hellesoy (aslak_hellesoy) Summary: mock#and_return should support multiple return values from passed in arguments Initial Comment: mock.and_return(1,2,3) should return the next passed in value each time the mock in invoked. For example, the_mock.should_receive(:foo).and_return(1, 2, 3) the_mock.foo # returns 1 the_mock.foo # returns 2 the_mock.foo # returns 3 ---------------------------------------------------------------------- >Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-22 15:24 Message: I thought I hadd attached the patch, but realise I hadn't and now I've lost the patch and the code :-( If my memory serves me right I changed the signature of Spec::Mocks::BaseExpectation#and_return from def and_return(value=nil, &return_block) to def and_return(*values, &return_block) And of course the implementation... ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-09-07 08:48 Message: Aslak - can you go ahead and make a new patch for this? Thanks, David ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-08-20 22:13 Message: Just to clarify - consecutive return values are already implemented. This is a semantic change so that instead of saying and_return([1, 2, 3]) we'll be saying and_return(1, 2, 3). I'm attaching a patch that implements the requested feature. The patch also makes the mock derive the implicitly expected invocation count (the number of args to and_return) and barfs if it's inconsistent with an explicit count. I haven't checked it into trunk because it's a substantial change that will break backwards compatibility, and I'd like others to look at it and comment first (and I was too lazy to make a branch). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5435&group_id=797 From noreply at rubyforge.org Sun Oct 22 19:01:09 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 22 Oct 2006 19:01:09 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-6277 ] debris left by stubbing (trunk) [submitted by dastels] Message-ID: <20061022230109.817A15241E38@rubyforge.org> Bugs item #6277, was opened at 2006-10-22 19:59 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6277&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) >Summary: debris left by stubbing (trunk) [submitted by dastels] Initial Comment: stubs leave some sort of residue in one file/context (#1) I have: context "Setting the name" do fixtures :users, :roles, :rights controller_name 'admin/dj' setup do roles(:admin).rights << rights(:admin) users(:rod).roles << roles(:admin) @session[:user] = users('rod').id @dj = Dj.new(:id => 1, :name => 'Joe') @dj.stub!(:update_attribute) @dj.stub!(:name).and_return('Dave') Dj.stub!(:find).and_return(@dj) Dj.should_receive(:find).with(:all).and_return([[@dj]]) end specify "should update the name" do @dj.should_receive(:update_attribute).with(:name, 'Dave') post 'set_dj_name', :id => 1, :value => 'Dave' end specify "should render the list" do post 'set_dj_name', :id => 1, :value => 'Dave' response.should_have_rjs :replace_html, 'itemList', /Dave/ end specify "should render the dj data" do post 'set_dj_name', :id => 1, :value => 'Dave' response.should_have_rjs :replace_html, 'itemData', /Dave/ end end in another (#2): context "Asking for a list" do fixtures :djs, :users, :roles, :rights controller_name 'admin/dj' setup do roles(:admin).rights << rights(:admin) users(:rod).roles << roles(:admin) @session[:user] = users('rod').id get 'list' end specify "should get some djs" do assigns('dj_list').should_not_be_nil end specify "should get all djs" do assigns('dj_list').size.should_equal 4 end end if #1 runs first, both specs in #2 fail (the invoked action calls Dj.find(:all). Failure is: "undefined method `find' for Dj:Class" if #2 is run alone, or first, everythign passes. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6277&group_id=797 From noreply at rubyforge.org Sun Oct 22 18:59:42 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 22 Oct 2006 18:59:42 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-6277 ] debris left by stubbing (trunk) Message-ID: <20061022225942.C9F5C5241E30@rubyforge.org> Bugs item #6277, was opened at 2006-10-22 18:59 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6277&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: debris left by stubbing (trunk) Initial Comment: stubs leave some sort of residue in one file/context (#1) I have: context "Setting the name" do fixtures :users, :roles, :rights controller_name 'admin/dj' setup do roles(:admin).rights << rights(:admin) users(:rod).roles << roles(:admin) @session[:user] = users('rod').id @dj = Dj.new(:id => 1, :name => 'Joe') @dj.stub!(:update_attribute) @dj.stub!(:name).and_return('Dave') Dj.stub!(:find).and_return(@dj) Dj.should_receive(:find).with(:all).and_return([[@dj]]) end specify "should update the name" do @dj.should_receive(:update_attribute).with(:name, 'Dave') post 'set_dj_name', :id => 1, :value => 'Dave' end specify "should render the list" do post 'set_dj_name', :id => 1, :value => 'Dave' response.should_have_rjs :replace_html, 'itemList', /Dave/ end specify "should render the dj data" do post 'set_dj_name', :id => 1, :value => 'Dave' response.should_have_rjs :replace_html, 'itemData', /Dave/ end end in another (#2): context "Asking for a list" do fixtures :djs, :users, :roles, :rights controller_name 'admin/dj' setup do roles(:admin).rights << rights(:admin) users(:rod).roles << roles(:admin) @session[:user] = users('rod').id get 'list' end specify "should get some djs" do assigns('dj_list').should_not_be_nil end specify "should get all djs" do assigns('dj_list').size.should_equal 4 end end if #1 runs first, both specs in #2 fail (the invoked action calls Dj.find(:all). Failure is: "undefined method `find' for Dj:Class" if #2 is run alone, or first, everythign passes. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6277&group_id=797 From lachiec at gmail.com Sun Oct 22 19:13:00 2006 From: lachiec at gmail.com (Lachie) Date: Mon, 23 Oct 2006 09:13:00 +1000 Subject: [rspec-devel] 100 % In-Reply-To: <36F50820-0EA1-4EE4-B8BD-25C988BA2F7A@daveastels.com> References: <8d961d900610171456i4919c1f0r6b55e3fa4c346cf4@mail.gmail.com> <36F50820-0EA1-4EE4-B8BD-25C988BA2F7A@daveastels.com> Message-ID: <2c5e719e0610221613l74f3fae9p4b094b415a6fff5b@mail.gmail.com> > > For the first time in history RSpec now has 100% coverage. > > All that means is that there is no code that is not executed during > the run. It says nothing about the logical coverage. For that we > need something like Jester. Is here a ruby version yet? Perhaps this would do the trick: http://blog.zenspider.com/archives/2006/10/heckle_another_rubyconf_hack.html From dastels at daveastels.com Sun Oct 22 22:28:19 2006 From: dastels at daveastels.com (Dave Astels) Date: Sun, 22 Oct 2006 23:28:19 -0300 Subject: [rspec-devel] 100 % In-Reply-To: <2c5e719e0610221613l74f3fae9p4b094b415a6fff5b@mail.gmail.com> References: <8d961d900610171456i4919c1f0r6b55e3fa4c346cf4@mail.gmail.com> <36F50820-0EA1-4EE4-B8BD-25C988BA2F7A@daveastels.com> <2c5e719e0610221613l74f3fae9p4b094b415a6fff5b@mail.gmail.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 22-Oct-06, at 8:13 PM, Lachie wrote: >>> For the first time in history RSpec now has 100% coverage. >> >> All that means is that there is no code that is not executed during >> the run. It says nothing about the logical coverage. For that we >> need something like Jester. Is here a ruby version yet? > > Perhaps this would do the trick: > http://blog.zenspider.com/archives/2006/10/ > heckle_another_rubyconf_hack.html yes.. exactly. Dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFFPCjDauez/L4x7g4RAqPnAJ9l5WOXqXzN/+JfuEyzY6MEF0WjcwCaA6Oq a//ObdxVzEmN8Ii9MistGhw= =he/9 -----END PGP SIGNATURE----- From noreply at rubyforge.org Sun Oct 22 21:32:41 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 22 Oct 2006 21:32:41 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-5435 ] mock#and_return should support multiple return values from passed in arguments Message-ID: <20061023013241.1C1975241E6B@rubyforge.org> Feature Requests item #5435, was opened at 2006-08-16 05:53 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5435&group_id=797 Category: None Group: None >Status: Closed Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Aslak Hellesoy (aslak_hellesoy) Summary: mock#and_return should support multiple return values from passed in arguments Initial Comment: mock.and_return(1,2,3) should return the next passed in value each time the mock in invoked. For example, the_mock.should_receive(:foo).and_return(1, 2, 3) the_mock.foo # returns 1 the_mock.foo # returns 2 the_mock.foo # returns 3 ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-10-23 01:32 Message: fixed in trunk see spec/spec/mocks/multiple_return_value_spec.rb ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-22 19:24 Message: I thought I hadd attached the patch, but realise I hadn't and now I've lost the patch and the code :-( If my memory serves me right I changed the signature of Spec::Mocks::BaseExpectation#and_return from def and_return(value=nil, &return_block) to def and_return(*values, &return_block) And of course the implementation... ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-09-07 12:48 Message: Aslak - can you go ahead and make a new patch for this? Thanks, David ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-08-21 02:13 Message: Just to clarify - consecutive return values are already implemented. This is a semantic change so that instead of saying and_return([1, 2, 3]) we'll be saying and_return(1, 2, 3). I'm attaching a patch that implements the requested feature. The patch also makes the mock derive the implicitly expected invocation count (the number of args to and_return) and barfs if it's inconsistent with an explicit count. I haven't checked it into trunk because it's a substantial change that will break backwards compatibility, and I'd like others to look at it and comment first (and I was too lazy to make a branch). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5435&group_id=797 From noreply at rubyforge.org Sun Oct 22 21:45:37 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 22 Oct 2006 21:45:37 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-5873 ] ARTS on RSpec on Rails Message-ID: <20061023014537.45E425241E72@rubyforge.org> Patches item #5873, was opened at 2006-09-24 06:53 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=5873&group_id=797 Category: None Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: ARTS on RSpec on Rails Initial Comment: Here is my patchfile for adding ARTS support to the rails plugin as mentioned in the mailing list and on my blog. I made one modification ( add require 'arts' to spec_helper) Jake ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-10-23 01:45 Message: this was released in 0.6.4 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=5873&group_id=797 From aslak.hellesoy at gmail.com Sun Oct 22 19:34:08 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Mon, 23 Oct 2006 01:34:08 +0200 Subject: [rspec-devel] 100 % In-Reply-To: <2c5e719e0610221613l74f3fae9p4b094b415a6fff5b@mail.gmail.com> References: <8d961d900610171456i4919c1f0r6b55e3fa4c346cf4@mail.gmail.com> <36F50820-0EA1-4EE4-B8BD-25C988BA2F7A@daveastels.com> <2c5e719e0610221613l74f3fae9p4b094b415a6fff5b@mail.gmail.com> Message-ID: <8d961d900610221634g7626416cx8ae9c272cc6cdb74@mail.gmail.com> On 10/23/06, Lachie wrote: > > > For the first time in history RSpec now has 100% coverage. > > > > All that means is that there is no code that is not executed during > > the run. It says nothing about the logical coverage. For that we > > need something like Jester. Is here a ruby version yet? > > Perhaps this would do the trick: > http://blog.zenspider.com/archives/2006/10/heckle_another_rubyconf_hack.html Now THATs interesting. Thanks for the pointer. I'll be following heckle closely and see if it can help us. Aslak > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From aslak.hellesoy at gmail.com Mon Oct 23 01:03:41 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Mon, 23 Oct 2006 07:03:41 +0200 Subject: [rspec-devel] 100 % In-Reply-To: References: <8d961d900610171456i4919c1f0r6b55e3fa4c346cf4@mail.gmail.com> <36F50820-0EA1-4EE4-B8BD-25C988BA2F7A@daveastels.com> <2c5e719e0610221613l74f3fae9p4b094b415a6fff5b@mail.gmail.com> Message-ID: <8d961d900610222203s191e62edq57d01f8addfcc1e1@mail.gmail.com> On 10/23/06, Dave Astels wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On 22-Oct-06, at 8:13 PM, Lachie wrote: > > >>> For the first time in history RSpec now has 100% coverage. > >> > >> All that means is that there is no code that is not executed during > >> the run. It says nothing about the logical coverage. For that we > >> need something like Jester. Is here a ruby version yet? > > > > Perhaps this would do the trick: > > http://blog.zenspider.com/archives/2006/10/ > > heckle_another_rubyconf_hack.html > > yes.. exactly. > No, not quite (yet). It's tightly coupled to Test::Unit. I've contacted Ryan and asked him if he wants to decouple it. It should be easy to do. I played a little bit with it in RSpec. It shouldn't be too hard to add native support for this in RSpec so you can say: spec .... --heckle qualifier Where qualifier is the name of a module, class or method. Example: --heckle Spec --heckle Spec::Expectations::Should::Base --heckle Spec::Expectations::Should::Base#find_supported_sym How cool would that be? > Dave > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.3 (Darwin) > > iD8DBQFFPCjDauez/L4x7g4RAqPnAJ9l5WOXqXzN/+JfuEyzY6MEF0WjcwCaA6Oq > a//ObdxVzEmN8Ii9MistGhw= > =he/9 > -----END PGP SIGNATURE----- > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dastels at daveastels.com Mon Oct 23 03:19:37 2006 From: dastels at daveastels.com (Dave Astels) Date: Mon, 23 Oct 2006 04:19:37 -0300 Subject: [rspec-devel] 100 % In-Reply-To: <8d961d900610222203s191e62edq57d01f8addfcc1e1@mail.gmail.com> References: <8d961d900610171456i4919c1f0r6b55e3fa4c346cf4@mail.gmail.com> <36F50820-0EA1-4EE4-B8BD-25C988BA2F7A@daveastels.com> <2c5e719e0610221613l74f3fae9p4b094b415a6fff5b@mail.gmail.com> <8d961d900610222203s191e62edq57d01f8addfcc1e1@mail.gmail.com> Message-ID: <17712AF4-73DB-41B9-A317-66DC29A745EC@daveastels.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 23-Oct-06, at 2:03 AM, aslak hellesoy wrote: > > No, not quite (yet). It's tightly coupled to Test::Unit. I've > contacted Ryan and asked him if he wants to decouple it. It should be > easy to do. > > I played a little bit with it in RSpec. It shouldn't be too hard to > add native support for this in RSpec so you can say: > > spec .... --heckle qualifier > > Where qualifier is the name of a module, class or method. Example: > > --heckle Spec > --heckle Spec::Expectations::Should::Base > --heckle Spec::Expectations::Should::Base#find_supported_sym > > How cool would that be? That'd be cool. Kevin Clark is hacking on it now. He said he pretty much tossed Ryan's POC and started from scratch with the implimentation (test driven). Dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFFPG0Kauez/L4x7g4RAhfTAJ97Gzf67OtBxUwvP6W395AeoYXGwQCghQjV 57rHiAtiL+gWXM6M+I8mo6Y= =5oPY -----END PGP SIGNATURE----- From noreply at rubyforge.org Mon Oct 23 09:10:55 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 23 Oct 2006 09:10:55 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-6283 ] refactoring of diff support to allow selectable formats and custom differs Message-ID: <20061023131057.F09E752412F8@rubyforge.org> Patches item #6283, was opened at 2006-10-23 23:10 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6283&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Lachie Cox (lachie) Assigned to: Nobody (None) Summary: refactoring of diff support to allow selectable formats and custom differs Initial Comment: Supports diff formats :unified (as default) and :context using the default differ Spec::Expectations::Differs::Default. Custom differs may be specified in the same way as custom formatters. spec --diff # unified spec --diff unified # unified spec --diff u # unified spec --diff context # context spec --diff c # context spec --require custom --diff Custom::Differ # loads Custom::Differ (caveat: you can't say spec --diff your_spec.rb as the option parser will eat the filename. alternatives: spec --diff -- your_spec.rb spec --diff= your_spec.rb spec --diff --colour your_spec.rb spec --diff u your_spec.rb ) I've tried to decouple the Differ workhorse from the hook into Spec::Expectations::Should::Base as much as possible, but it still leaves a bit to be desired. Spec::Expectations::Differs::Default is now the component with the diff/lcs dependency. The Differ duckbill is currently: #new(format=:unified,context_lines=3,colour=false) # in anticipation of ansi :) #diff_as_string(string1,string2,format=@format,context_lines=@context_lines) #diff_as_object(object1,object2,format=@format,context_lines=@context_lines) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6283&group_id=797 From noreply at rubyforge.org Mon Oct 23 14:04:25 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 23 Oct 2006 14:04:25 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-6283 ] refactoring of diff support to allow selectable formats and custom differs Message-ID: <20061023180425.830755241344@rubyforge.org> Patches item #6283, was opened at 2006-10-23 09:10 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6283&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Lachie Cox (lachie) Assigned to: Nobody (None) Summary: refactoring of diff support to allow selectable formats and custom differs Initial Comment: Supports diff formats :unified (as default) and :context using the default differ Spec::Expectations::Differs::Default. Custom differs may be specified in the same way as custom formatters. spec --diff # unified spec --diff unified # unified spec --diff u # unified spec --diff context # context spec --diff c # context spec --require custom --diff Custom::Differ # loads Custom::Differ (caveat: you can't say spec --diff your_spec.rb as the option parser will eat the filename. alternatives: spec --diff -- your_spec.rb spec --diff= your_spec.rb spec --diff --colour your_spec.rb spec --diff u your_spec.rb ) I've tried to decouple the Differ workhorse from the hook into Spec::Expectations::Should::Base as much as possible, but it still leaves a bit to be desired. Spec::Expectations::Differs::Default is now the component with the diff/lcs dependency. The Differ duckbill is currently: #new(format=:unified,context_lines=3,colour=false) # in anticipation of ansi :) #diff_as_string(string1,string2,format=@format,context_lines=@context_lines) #diff_as_object(object1,object2,format=@format,context_lines=@context_lines) ---------------------------------------------------------------------- >Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-23 14:04 Message: Great stuff. I think you forgot to attach the spec/expectations/differs/default.rb file though. It's required from option_parser.rb Further, diff_spec.rb is now empty. What's with that? Would this still give us 100% coverage? (rake spec verify_rcov). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6283&group_id=797 From aslak.hellesoy at gmail.com Mon Oct 23 17:28:11 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Mon, 23 Oct 2006 23:28:11 +0200 Subject: [rspec-devel] Running RSpec's specs Message-ID: <8d961d900610231428o323c2c25o31003eed2bc83bbd@mail.gmail.com> Just a heads up to those of you playing with the RSpec code: Running the specs is as easy as: rake spec verify_coverage If you want to do it from the command line: ruby -Ilib bin/spec spec --diff You *must* pass --diff, because some of the specs actually check the diffed error message (which would be different if you do *not* run with --diff). Also see the README for any gems you have to install. Aslak From noreply at rubyforge.org Mon Oct 23 20:07:35 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 23 Oct 2006 20:07:35 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-6283 ] refactoring of diff support to allow selectable formats and custom differs Message-ID: <20061024000735.4EA005241C7C@rubyforge.org> Patches item #6283, was opened at 2006-10-23 09:10 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6283&group_id=797 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Lachie Cox (lachie) >Assigned to: Aslak Hellesoy (aslak_hellesoy) Summary: refactoring of diff support to allow selectable formats and custom differs Initial Comment: Supports diff formats :unified (as default) and :context using the default differ Spec::Expectations::Differs::Default. Custom differs may be specified in the same way as custom formatters. spec --diff # unified spec --diff unified # unified spec --diff u # unified spec --diff context # context spec --diff c # context spec --require custom --diff Custom::Differ # loads Custom::Differ (caveat: you can't say spec --diff your_spec.rb as the option parser will eat the filename. alternatives: spec --diff -- your_spec.rb spec --diff= your_spec.rb spec --diff --colour your_spec.rb spec --diff u your_spec.rb ) I've tried to decouple the Differ workhorse from the hook into Spec::Expectations::Should::Base as much as possible, but it still leaves a bit to be desired. Spec::Expectations::Differs::Default is now the component with the diff/lcs dependency. The Differ duckbill is currently: #new(format=:unified,context_lines=3,colour=false) # in anticipation of ansi :) #diff_as_string(string1,string2,format=@format,context_lines=@context_lines) #diff_as_object(object1,object2,format=@format,context_lines=@context_lines) ---------------------------------------------------------------------- >Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-23 20:07 Message: Applied. Awesome! It will be in 0.7.0 ---------------------------------------------------------------------- Comment By: Lachie Cox (lachie) Date: 2006-10-23 19:28 Message: I've fixed the patch... my n00bish subversion knowledge was the problem, sorry! here are my notes from diff_spec.rb # TODO Need some way of speccing diff's Spec::Expectations::Should::Base extension # TODO The hook is explicitly turned off with the RSPEC_TESTING guard under "dogfood" specs # TODO The code is covered because the spec running these specs has --diff and the diff-hook switched on. I always use rake pre_commit to see if its all good, and it was. Its still against r954 because the work firewall blocks subversion. I also took the opportunity to simplify the Differ duckbill a little: #new(format=:unified,context_lines=3,colour=false) # in anticipation of ansi :) #diff_as_string(string1,string2) #diff_as_object(object1,object2) ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-23 14:04 Message: Great stuff. I think you forgot to attach the spec/expectations/differs/default.rb file though. It's required from option_parser.rb Further, diff_spec.rb is now empty. What's with that? Would this still give us 100% coverage? (rake spec verify_rcov). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6283&group_id=797 From noreply at rubyforge.org Mon Oct 23 19:28:12 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 23 Oct 2006 19:28:12 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-6283 ] refactoring of diff support to allow selectable formats and custom differs Message-ID: <20061023232814.AB26D5241BDE@rubyforge.org> Patches item #6283, was opened at 2006-10-23 23:10 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6283&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Lachie Cox (lachie) Assigned to: Nobody (None) Summary: refactoring of diff support to allow selectable formats and custom differs Initial Comment: Supports diff formats :unified (as default) and :context using the default differ Spec::Expectations::Differs::Default. Custom differs may be specified in the same way as custom formatters. spec --diff # unified spec --diff unified # unified spec --diff u # unified spec --diff context # context spec --diff c # context spec --require custom --diff Custom::Differ # loads Custom::Differ (caveat: you can't say spec --diff your_spec.rb as the option parser will eat the filename. alternatives: spec --diff -- your_spec.rb spec --diff= your_spec.rb spec --diff --colour your_spec.rb spec --diff u your_spec.rb ) I've tried to decouple the Differ workhorse from the hook into Spec::Expectations::Should::Base as much as possible, but it still leaves a bit to be desired. Spec::Expectations::Differs::Default is now the component with the diff/lcs dependency. The Differ duckbill is currently: #new(format=:unified,context_lines=3,colour=false) # in anticipation of ansi :) #diff_as_string(string1,string2,format=@format,context_lines=@context_lines) #diff_as_object(object1,object2,format=@format,context_lines=@context_lines) ---------------------------------------------------------------------- >Comment By: Lachie Cox (lachie) Date: 2006-10-24 09:28 Message: I've fixed the patch... my n00bish subversion knowledge was the problem, sorry! here are my notes from diff_spec.rb # TODO Need some way of speccing diff's Spec::Expectations::Should::Base extension # TODO The hook is explicitly turned off with the RSPEC_TESTING guard under "dogfood" specs # TODO The code is covered because the spec running these specs has --diff and the diff-hook switched on. I always use rake pre_commit to see if its all good, and it was. Its still against r954 because the work firewall blocks subversion. I also took the opportunity to simplify the Differ duckbill a little: #new(format=:unified,context_lines=3,colour=false) # in anticipation of ansi :) #diff_as_string(string1,string2) #diff_as_object(object1,object2) ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-24 04:04 Message: Great stuff. I think you forgot to attach the spec/expectations/differs/default.rb file though. It's required from option_parser.rb Further, diff_spec.rb is now empty. What's with that? Would this still give us 100% coverage? (rake spec verify_rcov). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6283&group_id=797 From noreply at rubyforge.org Tue Oct 24 02:51:26 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 24 Oct 2006 02:51:26 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-6265 ] should_raise should accept an Exception object Message-ID: <20061024065126.2993F5240DE8@rubyforge.org> Feature Requests item #6265, was opened at 2006-10-22 05:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6265&group_id=797 Category: mock module Group: None Status: Closed Priority: 3 Submitted By: Chad Woolley (thewoolleyman) Assigned to: Nobody (None) Summary: should_raise should accept an Exception object Initial Comment: So I can pass it an exception object with the message (or anything else) set on it. ---------------------------------------------------------------------- >Comment By: Chad Woolley (thewoolleyman) Date: 2006-10-24 06:51 Message: Yes, I meant "and_raise", it was a typo. I will try the Proc#should_raise and see if that works. Thanks, Chad ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-22 12:42 Message: I'm a little confused. You categorised this RFE in the mock module. RSpec mocks don't have a sould_raise method, but an and_raise method (which allows you to pass in an exception) http://rspec.rubyforge.org/documentation/mocks.html http://rubyforge.org/cgi-bin/viewvc.cgi/trunk/spec/spec/mocks/mock_spec.rb?revision=931&root=rspec Or perhaps you're talking about the Proc#should_raise method? It also allows you to pass an exception object: http://rubyforge.org/cgi-bin/viewvc.cgi/trunk/spec/spec/expectations/should/should_raise_spec.rb?root=rspec&view=co http://rspec.rubyforge.org/documentation/expectations.html If this doesn't work for you, please submit a failing spec. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6265&group_id=797 From dchelimsky at gmail.com Wed Oct 25 23:07:37 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 25 Oct 2006 22:07:37 -0500 Subject: [rspec-devel] 0.7 just around the corner Message-ID: <57c63afe0610252007w5354e448gb02ba82f4d430d8e@mail.gmail.com> Just a heads up that I've merged the changes from the rails plugin branch into the trunk. Feel free to grab the trunk to see how the rails plugin is shaping up. We're extending Test::Rails from ZenTest which gives us model, view, controller and helper specs. What we've done differently from ZenTest is to completely isolate the controller and view specs from each other - even under the hood. This means that errors in views will not cause controller specs to fail, nor vice versa. All that remains is documentation and a few more enhancements and we'll have 0.7. Cheers, David From noreply at rubyforge.org Wed Oct 25 18:06:20 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 25 Oct 2006 18:06:20 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-6317 ] c option for colorizing output does not work with rails_spec Message-ID: <20061025220620.7A9FC5241446@rubyforge.org> Bugs item #6317, was opened at 2006-10-25 17:06 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6317&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Ed Howland (edhowland) Assigned to: Nobody (None) Summary: c option for colorizing output does not work with rails_spec Initial Comment: When using the -c, --color or --colur option with rails_spec (the sever client) the output is black, not red or green as in using rhe normal spec command. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6317&group_id=797 From noreply at rubyforge.org Thu Oct 26 08:03:56 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 26 Oct 2006 08:03:56 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-6333 ] mock expectations should match regular expectations Message-ID: <20061026120357.3D59C5241423@rubyforge.org> Feature Requests item #6333, was opened at 2006-10-26 12:03 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6333&group_id=797 Category: mock module Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: David Chelimsky (dchelimsky) Summary: mock expectations should match regular expectations Initial Comment: context "a mock, in handling arguments" do setup do @mock = Mock.new("test mock") end specify "should match string against regexp" do @mock.should_receive(:random_call).with(/bcd/) @mock.random_call("abcde") end specify "should match regexp against regexp" do @mock.should_receive(:random_call).with(/bcd/) @mock.random_call(/bcd/) end specify "should fail if regexp does not match submitted string" do @mock.should_receive(:random_call).with(/bcd/) lambda { @mock.random_call("abc") }.should_raise(MockExpectationError) end specify "should fail if regexp does not match submitted regexp" do @mock.should_receive(:random_call).with(/bcd/) lambda { @mock.random_call(/bcde/) }.should_raise(MockExpectationError) end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6333&group_id=797 From noreply at rubyforge.org Thu Oct 26 07:56:11 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 26 Oct 2006 07:56:11 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-6094 ] rspec_on_rails pre-commit fails w/ -b option turned off Message-ID: <20061026115612.0B6BB524132E@rubyforge.org> Bugs item #6094, was opened at 2006-10-11 04:45 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6094&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: rspec_on_rails pre-commit fails w/ -b option turned off Initial Comment: This is in the trunk as of revision 868. Go to ~/vendor/rspec_on_rails/lib/tasks/bootstrap_rspec.rake and remove or comment the line that reads: t.spec_opts = ['-b'] Stand in ~/vendor/rspec_on-rails and execute: ../../bin/spec spec ../../bin/spec specs Everything should pass Now try this: rake pre_commit You'll get the following error (or similar): 1) NoMethodError in 'Given an rjs call to insert html in a div, a 'should_not_have_rjs' spec with no text but wrong element name should pass' You have a nil object when you didn't expect it! You might have expected an instance of Array. The error occured while evaluating nil.size generated_code/routing/generation.rb:30:in `generate_default_path' ./specs/should_not_have_rjs_spec.rb:99:in `setup' /Users/david/projects/ruby/rspec-all/trunk/vendor/rspec_on_rails/vendor/plugins/rspec/lib/extensions/spec/runner/context.rb:30:in `run' ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-21 14:20 Message: I cannot reproduce this on trunk. Does this still apply? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6094&group_id=797 From noreply at rubyforge.org Thu Oct 26 08:04:41 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 26 Oct 2006 08:04:41 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-6333 ] mock expectations should match regular expectations Message-ID: <20061026120441.D7D945241418@rubyforge.org> Feature Requests item #6333, was opened at 2006-10-26 12:03 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6333&group_id=797 Category: mock module Group: None >Status: Closed Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: David Chelimsky (dchelimsky) Summary: mock expectations should match regular expectations Initial Comment: context "a mock, in handling arguments" do setup do @mock = Mock.new("test mock") end specify "should match string against regexp" do @mock.should_receive(:random_call).with(/bcd/) @mock.random_call("abcde") end specify "should match regexp against regexp" do @mock.should_receive(:random_call).with(/bcd/) @mock.random_call(/bcd/) end specify "should fail if regexp does not match submitted string" do @mock.should_receive(:random_call).with(/bcd/) lambda { @mock.random_call("abc") }.should_raise(MockExpectationError) end specify "should fail if regexp does not match submitted regexp" do @mock.should_receive(:random_call).with(/bcd/) lambda { @mock.random_call(/bcde/) }.should_raise(MockExpectationError) end end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-10-26 12:04 Message: Added - will be in 0.7 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6333&group_id=797 From noreply at rubyforge.org Thu Oct 26 07:55:44 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 26 Oct 2006 07:55:44 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-5539 ] predicates do not work w/ rails Message-ID: <20061026115544.F1EDA524132E@rubyforge.org> Bugs item #5539, was opened at 2006-08-27 14:24 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=5539&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: predicates do not work w/ rails Initial Comment: Instead of doing: @dave.tracks.should_include Track.find_by_name("School's Out") I have to do: @dave.tracks.include?(Track.find_by_name("School's Out")).should_be true ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-09-06 05:56 Message: Jeff, It seems to me that the error message you're getting from rails is different than the one David and I are getting. I think you found a new bug. Can you file a separate ticket please? ---------------------------------------------------------------------- Comment By: Jeff Hoffman (wheeledone) Date: 2006-09-06 02:27 Message: I can confirm this behavior with a has_many: class Context < AR::B has_many :items end class Items < AR::B belongs_to :context end context "A new context" do setup do @context = Context.new end specify "should not have any items" do @context.action_items.should_be_empty end end Fails, saying 'empty?' is not available on ActionItem:Class. if I use should_satisfy, it works: @context.should_satisfy { |c| c.items.empty? } ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-08-29 22:33 Message: Yep. Same thing. ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-08-29 12:12 Message: I have added a spec for this in rspec_on_rails' person_spec.rb. It gives me: 1) TypeError in 'The Person model should include animals' wrong argument type Animal (expected Module) /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/base.rb:1129:in `method_missing' /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/associations/has_many_association.rb:102:in `method_missing' /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/base.rb:873:in `with_scope' /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/associations/has_many_association.rb:92:in `method_missing' ./spec/models/person_spec.rb:23:in `should include animals' /Users/aslakhellesoy/scm/rspec/trunk/vendor/rspec_on_rails/config/../vendor/plugins/rspec/lib/rspec_on_rails.rb:103:in `run' Finished in 0.545273 seconds 5 specifications, 1 failure rake aborted! Is that what you get? For now I have commented out the spec, but at least we have a starting point. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-08-27 14:25 Message: I *THINK* that this is a conflict between method_missing as used by should_helper and that of active_record. If correct, we solved this for sugar's use of method_missing and should be able to either reuse or duplicate that effort for should_helper. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=5539&group_id=797 From noreply at rubyforge.org Thu Oct 26 07:55:20 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 26 Oct 2006 07:55:20 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs - Rails Plugin-5487 ] UserEngine can not be loaded after rspec rails plugin is installed Message-ID: <20061026115520.7DE0652413F1@rubyforge.org> Bugs - Rails Plugin item #5487, was opened at 2006-08-22 08:19 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=9465&aid=5487&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: UserEngine can not be loaded after rspec rails plugin is installed Initial Comment: After install rspec rails plugin, ?rake test? can not run. `const_missing': uninitialized constant UserEngine (NameError) http://dongbin.org/articles/2006/08/22/userengine-can-not-be-loaded-after-rspec-rails-plugin-is-installed ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=9465&aid=5487&group_id=797 From noreply at rubyforge.org Thu Oct 26 07:55:26 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 26 Oct 2006 07:55:26 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-5539 ] predicates do not work w/ rails Message-ID: <20061026115526.E2014524141E@rubyforge.org> Bugs item #5539, was opened at 2006-08-27 14:24 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=5539&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: predicates do not work w/ rails Initial Comment: Instead of doing: @dave.tracks.should_include Track.find_by_name("School's Out") I have to do: @dave.tracks.include?(Track.find_by_name("School's Out")).should_be true ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-09-06 05:56 Message: Jeff, It seems to me that the error message you're getting from rails is different than the one David and I are getting. I think you found a new bug. Can you file a separate ticket please? ---------------------------------------------------------------------- Comment By: Jeff Hoffman (wheeledone) Date: 2006-09-06 02:27 Message: I can confirm this behavior with a has_many: class Context < AR::B has_many :items end class Items < AR::B belongs_to :context end context "A new context" do setup do @context = Context.new end specify "should not have any items" do @context.action_items.should_be_empty end end Fails, saying 'empty?' is not available on ActionItem:Class. if I use should_satisfy, it works: @context.should_satisfy { |c| c.items.empty? } ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-08-29 22:33 Message: Yep. Same thing. ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-08-29 12:12 Message: I have added a spec for this in rspec_on_rails' person_spec.rb. It gives me: 1) TypeError in 'The Person model should include animals' wrong argument type Animal (expected Module) /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/base.rb:1129:in `method_missing' /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/associations/has_many_association.rb:102:in `method_missing' /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/base.rb:873:in `with_scope' /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/associations/has_many_association.rb:92:in `method_missing' ./spec/models/person_spec.rb:23:in `should include animals' /Users/aslakhellesoy/scm/rspec/trunk/vendor/rspec_on_rails/config/../vendor/plugins/rspec/lib/rspec_on_rails.rb:103:in `run' Finished in 0.545273 seconds 5 specifications, 1 failure rake aborted! Is that what you get? For now I have commented out the spec, but at least we have a starting point. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-08-27 14:25 Message: I *THINK* that this is a conflict between method_missing as used by should_helper and that of active_record. If correct, we solved this for sugar's use of method_missing and should be able to either reuse or duplicate that effort for should_helper. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=5539&group_id=797 From noreply at rubyforge.org Thu Oct 26 07:56:00 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 26 Oct 2006 07:56:00 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs - Rails Plugin-6317 ] c option for colorizing output does not work with rails_spec Message-ID: <20061026115600.48C55524132E@rubyforge.org> Bugs - Rails Plugin item #6317, was opened at 2006-10-25 22:06 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=9465&aid=6317&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Ed Howland (edhowland) Assigned to: Nobody (None) Summary: c option for colorizing output does not work with rails_spec Initial Comment: When using the -c, --color or --colur option with rails_spec (the sever client) the output is black, not red or green as in using rhe normal spec command. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=9465&aid=6317&group_id=797 From noreply at rubyforge.org Thu Oct 26 08:22:47 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 26 Oct 2006 08:22:47 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-6334 ] should_have_key Message-ID: <20061026122247.1E3AA524141E@rubyforge.org> Feature Requests item #6334, was opened at 2006-10-26 12:22 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6334&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: David Chelimsky (dchelimsky) Summary: should_have_key Initial Comment: context "should_have_key" do specify "should pass when key is present" do lambda do {"a" => 1}.should_have_key("a") end.should_not_raise end specify "should fail when key is not present" do lambda do {"a" => 1}.should_have_key("b") end.should_fail_with '<{"a"=>1}> should have key: "b"' end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6334&group_id=797 From noreply at rubyforge.org Thu Oct 26 08:23:01 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 26 Oct 2006 08:23:01 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-6334 ] should_have_key Message-ID: <20061026122301.BA86852409FB@rubyforge.org> Feature Requests item #6334, was opened at 2006-10-26 12:22 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6334&group_id=797 Category: expectation module Group: None >Status: Closed Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: David Chelimsky (dchelimsky) Summary: should_have_key Initial Comment: context "should_have_key" do specify "should pass when key is present" do lambda do {"a" => 1}.should_have_key("a") end.should_not_raise end specify "should fail when key is not present" do lambda do {"a" => 1}.should_have_key("b") end.should_fail_with '<{"a"=>1}> should have key: "b"' end end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-10-26 12:23 Message: Added - will be in 0.7 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6334&group_id=797 From noreply at rubyforge.org Thu Oct 26 12:47:36 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 26 Oct 2006 12:47:36 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-6337 ] --colour broken on windows Message-ID: <20061026164736.536F45241601@rubyforge.org> Bugs item #6337, was opened at 2006-10-26 12:47 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6337&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Aslak Hellesoy (aslak_hellesoy) Assigned to: Aslak Hellesoy (aslak_hellesoy) Summary: --colour broken on windows Initial Comment: In r978 (trunk) the output for --colour is broken on windows. The summary is ok, but the dots are not. It looks like this: ?[32m.?[0m?[31mF?[0m?[32m.?[0m?[32m.?[0m?[32m.?[0m?[32m.?[0m?[32m.?[0m?[32m.?[0m?[32m.?[0m I haven't looked in detail, but it seems it's only the IO.puts method that works with escape characters, not IO.write (which is used for the dots). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6337&group_id=797 From noreply at rubyforge.org Thu Oct 26 12:19:01 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 26 Oct 2006 12:19:01 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-5634 ] support custom expectations Message-ID: <20061026161902.062D5524182F@rubyforge.org> Feature Requests item #5634, was opened at 2006-09-05 09:27 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5634&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: support custom expectations Initial Comment: Add a simple hook/API/whatever to allow people to easily build their own custom expectations. ---------------------------------------------------------------------- >Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-26 12:19 Message: Makes sense ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-10-26 12:00 Message: To clarify that last comment - this would still require monkey patching, but it would officially document a class to monkey patch that we would commit to maintain (in name). ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-10-26 11:56 Message: I prefer not to encourage monkey patching because it binds rspec's structure to specs outside our control. For example, I recently changed Spec::ShouldHelper and Spec::ShouldNegator to Spec::Expectations::Should and Spec::Expectations::Not respectively. This would break anyone's specs if they were monkey patching. I'm more inclined to expose a class specifically intended as a hook: Spec::CustomExpectations and have rspec look to that class to see if its instances respond to the method in question. That make sense? ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-09-08 13:48 Message: What about Ruby's monkeypathing feature? Just add methods to Spec::ShouldHelper and Spec::ShuoldNegator? I think this is just a matter of documentation. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5634&group_id=797 From noreply at rubyforge.org Thu Oct 26 11:49:09 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 26 Oct 2006 11:49:09 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-6058 ] should_have_tag should support " < name> " , " name" and :name Message-ID: <20061026154909.9165052414B1@rubyforge.org> Feature Requests item #6058, was opened at 2006-10-08 01:10 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6058&group_id=797 Category: None Group: None >Status: Closed Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: David Chelimsky (dchelimsky) >Summary: should_have_tag should support "<name>", "name" and :name Initial Comment: should_have_tag should support "", "name" and :name Right now it only supports "name" ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-10-26 15:49 Message: No it shouldn't. This just makes things confusing. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6058&group_id=797 From noreply at rubyforge.org Thu Oct 26 11:58:59 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 26 Oct 2006 11:58:59 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-5544 ] should_output (includes complete method definition) Message-ID: <20061026155859.A140D52414B8@rubyforge.org> Feature Requests item #5544, was opened at 2006-08-28 00:24 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5544&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Eero Saynatkari (esaynatkari) Assigned to: Nobody (None) Summary: should_output (includes complete method definition) Initial Comment: This expectation provides a way to specify program output. It takes into account Readline which refuses to allow use of StringIO or Tempfile. It is a bit ugly having to work around symbolic names but seems to work fine in my code. # Usage examples: lambda {UI.mainloop {|ui| ui.output 'foo'}}.should_output "foo\n" lambda {UI.mainloop {|ui| ui.output 'foo'}}.should_output /foo\n/ lambda {UI.mainloop {|ui| ui.error 'foo'}}.should_output "foo\n", :to => '$stderr' # Code: # Modify RSpec a little module Spec class ShouldHelper # Verify output from block is expected def output(expected, io = {:to => '$stdout'}) to = io[:to] # Store the old stream eval "old_to = #{to}" # Replace, work around Readline eval %{ #{to} = if $LOADED_FEATURES.grep(/readline/i).empty? StringIO.new '' else File.open '/tmp/rspec_output_#{$$}', 'w+' end # if readline } # eval @target.call eval(to).rewind output = eval(to).read # Match up case expected when Regexp output.should_match expected else output.should_equal expected end # case expected # Clean up ensure eval %{ #{to}, old_to = old_to, #{to} if old_to and old_to.kind_of? File require 'fileutils' old_to.close FileUtils.rm_rf old_to.path end # if old_to } # eval false end # output() end # ShouldHelper end # Spec ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-10-26 15:58 Message: Eero - I like this idea a lot. Would you consider submitting this as a patch against the trunk (pls indicate the revision number against which you are patching) including specs written in rspec. Thanks, David ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-08-29 12:04 Message: Looks good, but where is the test case for this? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5544&group_id=797 From noreply at rubyforge.org Thu Oct 26 11:33:11 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 26 Oct 2006 11:33:11 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-6091 ] should_raise should match error messages Message-ID: <20061026153312.EA05D52414C8@rubyforge.org> Feature Requests item #6091, was opened at 2006-10-11 02:10 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6091&group_id=797 Category: mock module Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: should_raise should match error messages Initial Comment: context "the should_raise expectation" do specify "should accept and verify an expected message using equality" do lambda do raise 'Hello' end.should_raise(StandardError).with_message "Hello" end specify "should accept and verify an expected message using regex matching" do lambda do raise 'Hello' end.should_raise(StandardError).with_message_matching /ello/ end end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-10-26 15:33 Message: Added - will be in 0.7 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6091&group_id=797 From noreply at rubyforge.org Thu Oct 26 11:48:37 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 26 Oct 2006 11:48:37 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-6091 ] should_raise should match error messages Message-ID: <20061026154838.1DB0F52414D5@rubyforge.org> Feature Requests item #6091, was opened at 2006-10-11 02:10 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6091&group_id=797 Category: mock module Group: None >Status: Closed Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: should_raise should match error messages Initial Comment: context "the should_raise expectation" do specify "should accept and verify an expected message using equality" do lambda do raise 'Hello' end.should_raise(StandardError).with_message "Hello" end specify "should accept and verify an expected message using regex matching" do lambda do raise 'Hello' end.should_raise(StandardError).with_message_matching /ello/ end end ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-10-26 15:33 Message: Added - will be in 0.7 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6091&group_id=797 From noreply at rubyforge.org Thu Oct 26 12:00:37 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 26 Oct 2006 12:00:37 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-5634 ] support custom expectations Message-ID: <20061026160037.C919552414B8@rubyforge.org> Feature Requests item #5634, was opened at 2006-09-05 13:27 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5634&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: support custom expectations Initial Comment: Add a simple hook/API/whatever to allow people to easily build their own custom expectations. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-10-26 16:00 Message: To clarify that last comment - this would still require monkey patching, but it would officially document a class to monkey patch that we would commit to maintain (in name). ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-10-26 15:56 Message: I prefer not to encourage monkey patching because it binds rspec's structure to specs outside our control. For example, I recently changed Spec::ShouldHelper and Spec::ShouldNegator to Spec::Expectations::Should and Spec::Expectations::Not respectively. This would break anyone's specs if they were monkey patching. I'm more inclined to expose a class specifically intended as a hook: Spec::CustomExpectations and have rspec look to that class to see if its instances respond to the method in question. That make sense? ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-09-08 17:48 Message: What about Ruby's monkeypathing feature? Just add methods to Spec::ShouldHelper and Spec::ShuoldNegator? I think this is just a matter of documentation. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5634&group_id=797 From noreply at rubyforge.org Thu Oct 26 11:56:23 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 26 Oct 2006 11:56:23 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-5634 ] support custom expectations Message-ID: <20061026155624.3C318524180A@rubyforge.org> Feature Requests item #5634, was opened at 2006-09-05 13:27 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5634&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: support custom expectations Initial Comment: Add a simple hook/API/whatever to allow people to easily build their own custom expectations. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-10-26 15:56 Message: I prefer not to encourage monkey patching because it binds rspec's structure to specs outside our control. For example, I recently changed Spec::ShouldHelper and Spec::ShouldNegator to Spec::Expectations::Should and Spec::Expectations::Not respectively. This would break anyone's specs if they were monkey patching. I'm more inclined to expose a class specifically intended as a hook: Spec::CustomExpectations and have rspec look to that class to see if its instances respond to the method in question. That make sense? ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-09-08 17:48 Message: What about Ruby's monkeypathing feature? Just add methods to Spec::ShouldHelper and Spec::ShuoldNegator? I think this is just a matter of documentation. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5634&group_id=797 From noreply at rubyforge.org Thu Oct 26 17:21:54 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 26 Oct 2006 17:21:54 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-6337 ] --colour broken on windows Message-ID: <20061026212154.5B32D52417AB@rubyforge.org> Bugs item #6337, was opened at 2006-10-26 12:47 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6337&group_id=797 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Aslak Hellesoy (aslak_hellesoy) Assigned to: Aslak Hellesoy (aslak_hellesoy) Summary: --colour broken on windows Initial Comment: In r978 (trunk) the output for --colour is broken on windows. The summary is ok, but the dots are not. It looks like this: ?[32m.?[0m?[31mF?[0m?[32m.?[0m?[32m.?[0m?[32m.?[0m?[32m.?[0m?[32m.?[0m?[32m.?[0m?[32m.?[0m I haven't looked in detail, but it seems it's only the IO.puts method that works with escape characters, not IO.write (which is used for the dots). ---------------------------------------------------------------------- >Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-26 17:21 Message: Fixed. Actually, it is only Kernel.write and Kernel.puts that work on Windows, so the code is now using that. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6337&group_id=797 From noreply at rubyforge.org Thu Oct 26 17:30:31 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 26 Oct 2006 17:30:31 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-5702 ] Spec generation from a YAML-format spec list proof-of-concept Message-ID: <20061026213031.AF5EE5241D93@rubyforge.org> Feature Requests item #5702, was opened at 2006-09-09 01:53 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5702&group_id=797 Category: None Group: None >Status: Closed Priority: 3 Submitted By: Eero Saynatkari (esaynatkari) >Assigned to: Aslak Hellesoy (aslak_hellesoy) Summary: Spec generation from a YAML-format spec list proof-of-concept Initial Comment: Hey. Quick hack, no access to Ruby right now but this should work--and you get to write the tests :) I find it much easier to write up the specs in a somewhat natural-looking syntax first (my thought pattern is not interrupted by trying to figure out how the spec is to be tested etc.) so I figured we can generate skeleton specs this way. Given a YAML file that looks something like this: --- context one: - Specification one This script will generate a 'proper' specification in the form of context 'context one' do specify 'Specification one' do raise NotImplementedError.new('"Specification one"') end end If there is a target file given, the script will use it to write to. If the target file already has contexts and specifications, the script will do two things: for all contexts it has that already exist in the file, it will insert its specifications to the top of that context. Any non-existing contexts will be appended to the file. The code should be easy to follow. #!/usr/bin/env ruby -w require 'yaml' # Output an entire context and all its specs def write_contexts(contexts, out = $stdout) # Write the remaining new specs out contexts.each {|context, specifications| out.puts %{context "#{context}" do} specifications.each {|spec| out.puts make_spec(spec) } # specifications.each out.puts "end" out.puts } # data.each end # context # Generate one empty spec def make_spec(spec) %{ specify "#{spec}" do\n raise NotImplementedError.new('"#{spec}"')\n end} end # specify if __FILE__ == $0 filename = ARGV.shift target = ARGV.shift data = YAML.load File.read(filename) # Target file if target old_data = File.readlines target if File.file? target # Overwrite the file interlacing File.open(target, 'w') {|f| (old_data || []).each {|line| # Write the data back f.puts line # Look for contexts if line =~ /^\s*context\s+('|")(.*?[^\])\1/ # Check if we have new specs for this context if data[$2] # Inject the new specs here data[$2].each {|spec| f.puts make_spec(spec)} # Remove the specs from the equation data.delete $2 end # if new specs end # if context } # old_data.each # Write the remaining contexts write_contexts data, f } # open target # Direct output else # Print each context and specification section in turn write_contexts data end # if target end # if __FILE__ ---------------------------------------------------------------------- >Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-26 17:30 Message: We're not going to implement this in the core. ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-09-12 16:51 Message: Nifty, but I'm not sold on the utility of this feature. You can achieve similar easy by using macros/live templates in your editor. It's a bit too bells and whistly for my taste. What do others think? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5702&group_id=797 From noreply at rubyforge.org Thu Oct 26 17:58:24 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 26 Oct 2006 17:58:24 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-5539 ] predicates do not work w/ rails Message-ID: <20061026215824.1EFAF5242070@rubyforge.org> Bugs item #5539, was opened at 2006-08-27 14:24 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=5539&group_id=797 Category: None Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: predicates do not work w/ rails Initial Comment: Instead of doing: @dave.tracks.should_include Track.find_by_name("School's Out") I have to do: @dave.tracks.include?(Track.find_by_name("School's Out")).should_be true ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-10-26 21:58 Message: Fixed - will be released in O.7 Just needed to tell ActiveRecord::Associations::HasManyAssociation to handle_underscores_for_rspec! ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-09-06 05:56 Message: Jeff, It seems to me that the error message you're getting from rails is different than the one David and I are getting. I think you found a new bug. Can you file a separate ticket please? ---------------------------------------------------------------------- Comment By: Jeff Hoffman (wheeledone) Date: 2006-09-06 02:27 Message: I can confirm this behavior with a has_many: class Context < AR::B has_many :items end class Items < AR::B belongs_to :context end context "A new context" do setup do @context = Context.new end specify "should not have any items" do @context.action_items.should_be_empty end end Fails, saying 'empty?' is not available on ActionItem:Class. if I use should_satisfy, it works: @context.should_satisfy { |c| c.items.empty? } ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-08-29 22:33 Message: Yep. Same thing. ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-08-29 12:12 Message: I have added a spec for this in rspec_on_rails' person_spec.rb. It gives me: 1) TypeError in 'The Person model should include animals' wrong argument type Animal (expected Module) /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/base.rb:1129:in `method_missing' /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/associations/has_many_association.rb:102:in `method_missing' /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/base.rb:873:in `with_scope' /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/associations/has_many_association.rb:92:in `method_missing' ./spec/models/person_spec.rb:23:in `should include animals' /Users/aslakhellesoy/scm/rspec/trunk/vendor/rspec_on_rails/config/../vendor/plugins/rspec/lib/rspec_on_rails.rb:103:in `run' Finished in 0.545273 seconds 5 specifications, 1 failure rake aborted! Is that what you get? For now I have commented out the spec, but at least we have a starting point. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-08-27 14:25 Message: I *THINK* that this is a conflict between method_missing as used by should_helper and that of active_record. If correct, we solved this for sugar's use of method_missing and should be able to either reuse or duplicate that effort for should_helper. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=5539&group_id=797 From noreply at rubyforge.org Thu Oct 26 17:33:26 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 26 Oct 2006 17:33:26 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-5625 ] specification reuse: specify & amp; amp; amp; context & amp; amp; amp; helper methods Message-ID: <20061026213326.404B55241F2D@rubyforge.org> Feature Requests item #5625, was opened at 2006-09-04 19:19 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5625&group_id=797 >Category: runner module Group: None >Status: Closed Priority: 3 Submitted By: Suraj Kurapati (snk) >Assigned to: David Chelimsky (dchelimsky) Summary: specification reuse: specify &amp;amp;amp; context &amp;amp;amp; helper methods Initial Comment: Hello, I'm using BDD via RSpec to develop and verify hardware. My specifications tend to be long and sequential, such as: An empty cache - should miss when read A read miss on an empty cache - should be passed to a lower-level cache A read miss response from a lower-level cache to an empty cache - should cause the empty cache to respond to the miss In these situations, the setup() for each context is determined by the conditions present when the previous context/specify() has finished. For example, it is similar to a specification like this: 1 + 1 - should be 2 2 + 5 - should be 7 7 + 0.99 - should be 7.99 See the pattern? I could use helper methods to minimize duplication of logic, but... there is still duplication of variables. So, here are three ideas which can simplify reuse of the conditions present at the _end_ of a specify() as a context for new specify()s. I like the first one best. ## nested specify() statements are evaluated as encountered by their parent. context "1 + 1" do setup do @sum = 1 + 1 end specify "should be 2" do @sum.should_equal 2 specify "should be 7" do @sum += 5 @sum.should_equal 7 specify "should be 7.99" do @sum += 0.99 @sum.should_equal 7.99 end end end end ## specify() returns its block, which can then be invoked elsewhere. context "1 + 1" do setup do @sum = 1 + 1 end s1 = specify "should be 2" do @sum = 1 + 1 @sum.should_equal 2 end s2 = specify "should be 7" do s1.call @sum += 5 @sum.should_equal 7 end s3 = specify "should be 7.99" do s2.call @sum += 0.99 @sum.should_equal 7.99 end end ## Rake-style prerequisites in specifications context "1 + 1" do setup do @sum = 1 + 1 end specify "should be 2" do @sum = 1 + 1 @sum.should_equal 2 end specify "should be 7" => ["should be 2"] do @sum += 5 @sum.should_equal 7 end specify "should be 7.99" => ["should be 7"] do @sum += 0.99 @sum.should_equal 7.99 end end Thanks for your consideration. ---------------------------------------------------------------------- >Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-26 17:33 Message: Based on previous discussions we have decided not to implement this feature. See http://butunclebob.com/ArticleS.DavidChelimsky.SpecOrganization for more detail ---------------------------------------------------------------------- Comment By: Suraj Kurapati (snk) Date: 2006-09-04 19:32 Message: I just want to emphasize that what is needed is a way to reuse the conditions present at the end of a specify() as the conditions present at the start of another specify(). My ideas on how this will look when impemented don't really matter. I'm sure that you RSpec developers can think of a nicer ways to augment the DSL. Thanks for your consideration. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=5625&group_id=797 From noreply at rubyforge.org Fri Oct 27 04:01:08 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 27 Oct 2006 04:01:08 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-4690 ] Ordering of mock calls doesn't work in block mode Message-ID: <20061027080108.961A55240DE5@rubyforge.org> Bugs item #4690, was opened at 2006-06-06 16:31 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=4690&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Aslak Hellesoy (aslak_hellesoy) Assigned to: Nobody (None) Summary: Ordering of mock calls doesn't work in block mode Initial Comment: Two failing (and disabled) tests have been added to mock_ordering_test.rb to demonstrate this. ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2006-10-27 01:01 Message: I'm getting an issue with the ordered should_receive(:doit) being called twice. It seems the first expectation wins and the second expectation never gets considered. It also seems that the block is a red herring. try: specify "should pass two calls in order to the same method" do @mock.should_receive(:doit).ordered.with("a1", "b1") @mock.should_receive(:doit).ordered.with("a1", "b2") @mock.doit "a1", "b1" @mock.doit "b1", "b2" @mock.__verify end ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-14 06:19 Message: Moving the tests here: def FIXME_test_two_in_order_calls_with_block @mock.should_receive(:doit).ordered do |a, b| a.should_equal "a1" a.should_equal "b1" end @mock.should_receive(:doit).ordered do |a, b| a.should_equal "a2" a.should_equal "b2" end @mock.doit "a1", "b1" @mock.doit "b1", "b2" @mock.__verify end def FIXME_test_two_out_of_order_calls_with_block @mock.should_receive(:doit).ordered do |a, b| a.should_equal "a1" a.should_equal "b1" end @mock.should_receive(:doit).ordered do |a, b| a.should_equal "a2" a.should_equal "b2" end @mock.doit "b1", "b2" @mock.doit "a1", "b1" @mock.__verify end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=4690&group_id=797 From noreply at rubyforge.org Fri Oct 27 12:10:27 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 27 Oct 2006 12:10:27 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-4690 ] Ordering of mock calls doesn't work in block mode Message-ID: <20061027161028.44CDD5241519@rubyforge.org> Bugs item #4690, was opened at 2006-06-06 23:31 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=4690&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Aslak Hellesoy (aslak_hellesoy) Assigned to: Nobody (None) Summary: Ordering of mock calls doesn't work in block mode Initial Comment: Two failing (and disabled) tests have been added to mock_ordering_test.rb to demonstrate this. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-10-27 16:10 Message: Brian - in your example, the second should receive says "a1", "b2", but the second call says "b1", "b2". Was that your intent? If you align these the spec passes. specify "should pass two calls in order to the same method" do @mock.should_receive(:doit).ordered.with("a1", "b1") @mock.should_receive(:doit).ordered.with("a1", "b2") @mock.doit "a1", "b1" @mock.doit "b1", "b2" @mock.__verify end ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2006-10-27 08:01 Message: I'm getting an issue with the ordered should_receive(:doit) being called twice. It seems the first expectation wins and the second expectation never gets considered. It also seems that the block is a red herring. try: specify "should pass two calls in order to the same method" do @mock.should_receive(:doit).ordered.with("a1", "b1") @mock.should_receive(:doit).ordered.with("a1", "b2") @mock.doit "a1", "b1" @mock.doit "b1", "b2" @mock.__verify end ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-14 13:19 Message: Moving the tests here: def FIXME_test_two_in_order_calls_with_block @mock.should_receive(:doit).ordered do |a, b| a.should_equal "a1" a.should_equal "b1" end @mock.should_receive(:doit).ordered do |a, b| a.should_equal "a2" a.should_equal "b2" end @mock.doit "a1", "b1" @mock.doit "b1", "b2" @mock.__verify end def FIXME_test_two_out_of_order_calls_with_block @mock.should_receive(:doit).ordered do |a, b| a.should_equal "a1" a.should_equal "b1" end @mock.should_receive(:doit).ordered do |a, b| a.should_equal "a2" a.should_equal "b2" end @mock.doit "b1", "b2" @mock.doit "a1", "b1" @mock.__verify end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=4690&group_id=797 From dgoodlad at gmail.com Fri Oct 27 18:12:02 2006 From: dgoodlad at gmail.com (David Goodlad) Date: Fri, 27 Oct 2006 15:12:02 -0700 Subject: [rspec-devel] 0.7 just around the corner In-Reply-To: <57c63afe0610252007w5354e448gb02ba82f4d430d8e@mail.gmail.com> References: <57c63afe0610252007w5354e448gb02ba82f4d430d8e@mail.gmail.com> Message-ID: On 10/25/06, David Chelimsky wrote: > Just a heads up that I've merged the changes from the rails plugin > branch into the trunk. Feel free to grab the trunk to see how the > rails plugin is shaping up. We're extending Test::Rails from ZenTest > which gives us model, view, controller and helper specs. What we've > done differently from ZenTest is to completely isolate the controller > and view specs from each other - even under the hood. This means that > errors in views will not cause controller specs to fail, nor vice > versa. Great to hear that the ZenTest m/v/c/h test separation is now available in rspec. Hopefully it won't affect too many of my existing specs! Dave -- Dave Goodlad dgoodlad at gmail.com or dave at goodlad.ca http://david.goodlad.ca/ From noreply at rubyforge.org Fri Oct 27 20:46:47 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 27 Oct 2006 20:46:47 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-4690 ] Ordering of mock calls doesn't work in block mode Message-ID: <20061028004647.DDB83524218B@rubyforge.org> Bugs item #4690, was opened at 2006-06-06 16:31 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=4690&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Aslak Hellesoy (aslak_hellesoy) Assigned to: Nobody (None) Summary: Ordering of mock calls doesn't work in block mode Initial Comment: Two failing (and disabled) tests have been added to mock_ordering_test.rb to demonstrate this. ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2006-10-27 17:46 Message: Sorry. My mistake. I tried to look into this too late. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-10-27 09:10 Message: Brian - in your example, the second should receive says "a1", "b2", but the second call says "b1", "b2". Was that your intent? If you align these the spec passes. specify "should pass two calls in order to the same method" do @mock.should_receive(:doit).ordered.with("a1", "b1") @mock.should_receive(:doit).ordered.with("a1", "b2") @mock.doit "a1", "b1" @mock.doit "b1", "b2" @mock.__verify end ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2006-10-27 01:01 Message: I'm getting an issue with the ordered should_receive(:doit) being called twice. It seems the first expectation wins and the second expectation never gets considered. It also seems that the block is a red herring. try: specify "should pass two calls in order to the same method" do @mock.should_receive(:doit).ordered.with("a1", "b1") @mock.should_receive(:doit).ordered.with("a1", "b2") @mock.doit "a1", "b1" @mock.doit "b1", "b2" @mock.__verify end ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-14 06:19 Message: Moving the tests here: def FIXME_test_two_in_order_calls_with_block @mock.should_receive(:doit).ordered do |a, b| a.should_equal "a1" a.should_equal "b1" end @mock.should_receive(:doit).ordered do |a, b| a.should_equal "a2" a.should_equal "b2" end @mock.doit "a1", "b1" @mock.doit "b1", "b2" @mock.__verify end def FIXME_test_two_out_of_order_calls_with_block @mock.should_receive(:doit).ordered do |a, b| a.should_equal "a1" a.should_equal "b1" end @mock.should_receive(:doit).ordered do |a, b| a.should_equal "a2" a.should_equal "b2" end @mock.doit "b1", "b2" @mock.doit "a1", "b1" @mock.__verify end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=4690&group_id=797 From dchelimsky at gmail.com Sat Oct 28 12:46:54 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 28 Oct 2006 11:46:54 -0500 Subject: [rspec-devel] Fwd: [Rspec-users] RSpec, REST and different formats In-Reply-To: <57c63afe0610280946q1232a036g555f7a1d2067683d@mail.gmail.com> References: <246e442a0610280037o29bc2a6cia41e489d5ca1393c@mail.gmail.com> <57c63afe0610280946q1232a036g555f7a1d2067683d@mail.gmail.com> Message-ID: <57c63afe0610280946i1cb7bfd4j5bceccb635984a65@mail.gmail.com> On 10/28/06, Jeff Dean wrote: > Is anyone using RSpec with RESTful rails apps? In my rails controllers I > check request.respond_to? and render different views accordingly. > > I noticed that the get method in the rails plugin doesn't accept headers: > > controller_mixin.rb line 92 > def get(action, parameters = nil) > @request.env['REQUEST_METHOD'] = 'GET' > process action, parameters > end > > Has anyone found a way around this? Hi Jeff. We're getting ready to release a new version of the plugin so now is a good time to at least consider addressing this. Can you write an example of how you'd want to be able to write the spec (and controller code) for a restful get request? Don't worry about how rspec would do it. I just want to know what you want it to do. Thanks, David > > Jeff > > _______________________________________________ > Rspec-users mailing list > Rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > > From noreply at rubyforge.org Sat Oct 28 11:23:58 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 28 Oct 2006 11:23:58 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs - Rails Plugin-6375 ] rails_spec does not isolate tests when using database Message-ID: <20061028152358.5AF3D524187A@rubyforge.org> Bugs - Rails Plugin item #6375, was opened at 2006-10-28 11:23 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=9465&aid=6375&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: rails_spec does not isolate tests when using database Initial Comment: Specs are not isolated between runs I have model Employee with validates_uniqueness_of :login then in my EmployeeSpec (only 1 context, 1 spec) i execute: employee = Employee.new(valid_employee_attributes) employee.save.should.be true I do NOT load fixtures. When I run this spec for the FIRST time -- it is succeeds. But when I run it once again (with spec, or with use of rails_spec_server) it fails: Spec::Expectations::ExpectationNotMetError in 'New Employee should have all attributes set' "has already been taken" should be nil Which means that there is already an Employee with such name. Then I checked my database server and it showed (SELECT * FROM employees) existing records!!!. I also fetched all employees within the spec before new record creation: ee = Employee.find :all ee.each do |x| puts "#{x.id} #{x.login}" end which showed records from DB, but there should be no records -- as this is test DB. That means that this test (spec) was not isolated. I used self.use_transactional_fixtures set to 'true' and 'false' ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=9465&aid=6375&group_id=797 From aslak.hellesoy at gmail.com Sat Oct 28 18:44:04 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sat, 28 Oct 2006 23:44:04 +0100 Subject: [rspec-devel] Rails questions to this list Message-ID: <8d961d900610281544v7710a135ib965b828607e4f85@mail.gmail.com> Can we put up a page on the web page that says something like: If you think you have found a bug in RSpec on Rails then: 1) Code a similar test in Test::Unit first to make sure it's an issue that only happens in RSpec on Rails (if possible) 2) Submit complete code that allows us to reproduce it Then we can point people to that page if we think we're dealing with non-rspec issues (dumb user error or inherent rails issues) Aslak From noreply at rubyforge.org Sat Oct 28 13:49:01 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 28 Oct 2006 13:49:01 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs - Rails Plugin-6375 ] rails_spec does not isolate tests when using database Message-ID: <20061028174901.4BE8AA970009@rubyforge.org> Bugs - Rails Plugin item #6375, was opened at 2006-10-28 15:23 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=9465&aid=6375&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: rails_spec does not isolate tests when using database Initial Comment: Specs are not isolated between runs I have model Employee with validates_uniqueness_of :login then in my EmployeeSpec (only 1 context, 1 spec) i execute: employee = Employee.new(valid_employee_attributes) employee.save.should.be true I do NOT load fixtures. When I run this spec for the FIRST time -- it is succeeds. But when I run it once again (with spec, or with use of rails_spec_server) it fails: Spec::Expectations::ExpectationNotMetError in 'New Employee should have all attributes set' "has already been taken" should be nil Which means that there is already an Employee with such name. Then I checked my database server and it showed (SELECT * FROM employees) existing records!!!. I also fetched all employees within the spec before new record creation: ee = Employee.find :all ee.each do |x| puts "#{x.id} #{x.login}" end which showed records from DB, but there should be no records -- as this is test DB. That means that this test (spec) was not isolated. I used self.use_transactional_fixtures set to 'true' and 'false' ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-10-28 17:49 Message: Since you were playing with self.use_transactional_fixtures, you may have created the record when that was set to false. Can you please manually ensure that your database table is empty, set self.use_transactional_fixtures to true and run the spec twice and report back if this still happens? Thanks, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=9465&aid=6375&group_id=797 From noreply at rubyforge.org Sat Oct 28 16:58:59 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 28 Oct 2006 16:58:59 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs - Rails Plugin-6375 ] rails_spec does not isolate tests when using database Message-ID: <20061028205859.4C19152418DC@rubyforge.org> Bugs - Rails Plugin item #6375, was opened at 2006-10-28 17:23 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=9465&aid=6375&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: rails_spec does not isolate tests when using database Initial Comment: Specs are not isolated between runs I have model Employee with validates_uniqueness_of :login then in my EmployeeSpec (only 1 context, 1 spec) i execute: employee = Employee.new(valid_employee_attributes) employee.save.should.be true I do NOT load fixtures. When I run this spec for the FIRST time -- it is succeeds. But when I run it once again (with spec, or with use of rails_spec_server) it fails: Spec::Expectations::ExpectationNotMetError in 'New Employee should have all attributes set' "has already been taken" should be nil Which means that there is already an Employee with such name. Then I checked my database server and it showed (SELECT * FROM employees) existing records!!!. I also fetched all employees within the spec before new record creation: ee = Employee.find :all ee.each do |x| puts "#{x.id} #{x.login}" end which showed records from DB, but there should be no records -- as this is test DB. That means that this test (spec) was not isolated. I used self.use_transactional_fixtures set to 'true' and 'false' ---------------------------------------------------------------------- Comment By: Michal Bakowski (dr_bonzo) Date: 2006-10-28 22:58 Message: Source of bug found. I started building this spec from scratch: ---8<------------------------------- Employee with validates_uniqueness_of :login (...) context "New Employee" do include EmployeeSpecHelper def setup # important, I also used in in previous case, but not included it in code listing puts "====================" end specify "should have all attributes set" do employee = Employee.new(valid_employee_attributes) employee.employee_group_id = 0 employee.save.should.be true end end ================================8<============ And I have finally located source of this bug. It was this simple 'setup' method (I needed it for debugging (separating debug messages) spec as it does not have 'breakpoint' feature :( ). OMG, my mistake (RTFM): it is not "def setup..." (T::U way) but "setup do..." (RS) How to reproduce bug: I clear the DB. Run this spec (spec .../employee_spec.rb) It passes. There is 1 record in DB Run it once more I get the error: --- Solution I remove 'setup' method from spec Run this spec (spec .../employee_spec.rb) It passes. DB is empty Run it once more And it is ok (spec passed, DB empty) Thanks for motivation, as I returned to Test::Unit after that failure :) Michal Bakowski ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-10-28 19:49 Message: Since you were playing with self.use_transactional_fixtures, you may have created the record when that was set to false. Can you please manually ensure that your database table is empty, set self.use_transactional_fixtures to true and run the spec twice and report back if this still happens? Thanks, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=9465&aid=6375&group_id=797 From noreply at rubyforge.org Sat Oct 28 18:40:23 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 28 Oct 2006 18:40:23 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs - Rails Plugin-6375 ] rails_spec does not isolate tests when using database Message-ID: <20061028224024.3F8AD52418F0@rubyforge.org> Bugs - Rails Plugin item #6375, was opened at 2006-10-28 11:23 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=9465&aid=6375&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: rails_spec does not isolate tests when using database Initial Comment: Specs are not isolated between runs I have model Employee with validates_uniqueness_of :login then in my EmployeeSpec (only 1 context, 1 spec) i execute: employee = Employee.new(valid_employee_attributes) employee.save.should.be true I do NOT load fixtures. When I run this spec for the FIRST time -- it is succeeds. But when I run it once again (with spec, or with use of rails_spec_server) it fails: Spec::Expectations::ExpectationNotMetError in 'New Employee should have all attributes set' "has already been taken" should be nil Which means that there is already an Employee with such name. Then I checked my database server and it showed (SELECT * FROM employees) existing records!!!. I also fetched all employees within the spec before new record creation: ee = Employee.find :all ee.each do |x| puts "#{x.id} #{x.login}" end which showed records from DB, but there should be no records -- as this is test DB. That means that this test (spec) was not isolated. I used self.use_transactional_fixtures set to 'true' and 'false' ---------------------------------------------------------------------- >Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-28 18:40 Message: Please submit your entire spec so we can reproduce this. (what's the definition of valid_employee_attributes)? You're not running with fixtures, so the employees table is not being cleaned between runs. I suspect that you're trying to save a person with an explicit id, and that that's why it's failing the 2nd time. If you run with Test::Unit, I suspect you get the same result. ---------------------------------------------------------------------- Comment By: Michal Bakowski (dr_bonzo) Date: 2006-10-28 16:58 Message: Source of bug found. I started building this spec from scratch: ---8<------------------------------- Employee with validates_uniqueness_of :login (...) context "New Employee" do include EmployeeSpecHelper def setup # important, I also used in in previous case, but not included it in code listing puts "====================" end specify "should have all attributes set" do employee = Employee.new(valid_employee_attributes) employee.employee_group_id = 0 employee.save.should.be true end end ================================8<============ And I have finally located source of this bug. It was this simple 'setup' method (I needed it for debugging (separating debug messages) spec as it does not have 'breakpoint' feature :( ). OMG, my mistake (RTFM): it is not "def setup..." (T::U way) but "setup do..." (RS) How to reproduce bug: I clear the DB. Run this spec (spec .../employee_spec.rb) It passes. There is 1 record in DB Run it once more I get the error: --- Solution I remove 'setup' method from spec Run this spec (spec .../employee_spec.rb) It passes. DB is empty Run it once more And it is ok (spec passed, DB empty) Thanks for motivation, as I returned to Test::Unit after that failure :) Michal Bakowski ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-10-28 13:49 Message: Since you were playing with self.use_transactional_fixtures, you may have created the record when that was set to false. Can you please manually ensure that your database table is empty, set self.use_transactional_fixtures to true and run the spec twice and report back if this still happens? Thanks, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=9465&aid=6375&group_id=797 From noreply at rubyforge.org Sun Oct 29 03:33:10 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 29 Oct 2006 03:33:10 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs - Rails Plugin-6375 ] rails_spec does not isolate tests when using database Message-ID: <20061029083310.46D7D5240ED9@rubyforge.org> Bugs - Rails Plugin item #6375, was opened at 2006-10-28 15:23 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=9465&aid=6375&group_id=797 Category: None Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: rails_spec does not isolate tests when using database Initial Comment: Specs are not isolated between runs I have model Employee with validates_uniqueness_of :login then in my EmployeeSpec (only 1 context, 1 spec) i execute: employee = Employee.new(valid_employee_attributes) employee.save.should.be true I do NOT load fixtures. When I run this spec for the FIRST time -- it is succeeds. But when I run it once again (with spec, or with use of rails_spec_server) it fails: Spec::Expectations::ExpectationNotMetError in 'New Employee should have all attributes set' "has already been taken" should be nil Which means that there is already an Employee with such name. Then I checked my database server and it showed (SELECT * FROM employees) existing records!!!. I also fetched all employees within the spec before new record creation: ee = Employee.find :all ee.each do |x| puts "#{x.id} #{x.login}" end which showed records from DB, but there should be no records -- as this is test DB. That means that this test (spec) was not isolated. I used self.use_transactional_fixtures set to 'true' and 'false' ---------------------------------------------------------------------- Comment By: Michal Bakowski (dr_bonzo) Date: 2006-10-29 07:35 Message: It was MY mistake which caused this rSpec behaviour. The problem was with the method "setup" which I had definded within the spec: def setup .... end and that's not the way to implement 'setup' within Specs. When i run this spec with 'setup' method defined it behaved as I had written before. When I removed this method everything was all right. And database was empty after successfully passed spec. I think there's no need to post whole spec, as it was my missuse of RSpec. Michal Bakowski ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-28 22:40 Message: Please submit your entire spec so we can reproduce this. (what's the definition of valid_employee_attributes)? You're not running with fixtures, so the employees table is not being cleaned between runs. I suspect that you're trying to save a person with an explicit id, and that that's why it's failing the 2nd time. If you run with Test::Unit, I suspect you get the same result. ---------------------------------------------------------------------- Comment By: Michal Bakowski (dr_bonzo) Date: 2006-10-28 20:58 Message: Source of bug found. I started building this spec from scratch: ---8<------------------------------- Employee with validates_uniqueness_of :login (...) context "New Employee" do include EmployeeSpecHelper def setup # important, I also used in in previous case, but not included it in code listing puts "====================" end specify "should have all attributes set" do employee = Employee.new(valid_employee_attributes) employee.employee_group_id = 0 employee.save.should.be true end end ================================8<============ And I have finally located source of this bug. It was this simple 'setup' method (I needed it for debugging (separating debug messages) spec as it does not have 'breakpoint' feature :( ). OMG, my mistake (RTFM): it is not "def setup..." (T::U way) but "setup do..." (RS) How to reproduce bug: I clear the DB. Run this spec (spec .../employee_spec.rb) It passes. There is 1 record in DB Run it once more I get the error: --- Solution I remove 'setup' method from spec Run this spec (spec .../employee_spec.rb) It passes. DB is empty Run it once more And it is ok (spec passed, DB empty) Thanks for motivation, as I returned to Test::Unit after that failure :) Michal Bakowski ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-10-28 17:49 Message: Since you were playing with self.use_transactional_fixtures, you may have created the record when that was set to false. Can you please manually ensure that your database table is empty, set self.use_transactional_fixtures to true and run the spec twice and report back if this still happens? Thanks, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=9465&aid=6375&group_id=797 From noreply at rubyforge.org Sun Oct 29 02:35:50 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 29 Oct 2006 02:35:50 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs - Rails Plugin-6375 ] rails_spec does not isolate tests when using database Message-ID: <20061029073550.C7CAF5240EA8@rubyforge.org> Bugs - Rails Plugin item #6375, was opened at 2006-10-28 17:23 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=9465&aid=6375&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: rails_spec does not isolate tests when using database Initial Comment: Specs are not isolated between runs I have model Employee with validates_uniqueness_of :login then in my EmployeeSpec (only 1 context, 1 spec) i execute: employee = Employee.new(valid_employee_attributes) employee.save.should.be true I do NOT load fixtures. When I run this spec for the FIRST time -- it is succeeds. But when I run it once again (with spec, or with use of rails_spec_server) it fails: Spec::Expectations::ExpectationNotMetError in 'New Employee should have all attributes set' "has already been taken" should be nil Which means that there is already an Employee with such name. Then I checked my database server and it showed (SELECT * FROM employees) existing records!!!. I also fetched all employees within the spec before new record creation: ee = Employee.find :all ee.each do |x| puts "#{x.id} #{x.login}" end which showed records from DB, but there should be no records -- as this is test DB. That means that this test (spec) was not isolated. I used self.use_transactional_fixtures set to 'true' and 'false' ---------------------------------------------------------------------- Comment By: Michal Bakowski (dr_bonzo) Date: 2006-10-29 08:35 Message: It was MY mistake which caused this rSpec behaviour. The problem was with the method "setup" which I had definded within the spec: def setup .... end and that's not the way to implement 'setup' within Specs. When i run this spec with 'setup' method defined it behaved as I had written before. When I removed this method everything was all right. And database was empty after successfully passed spec. I think there's no need to post whole spec, as it was my missuse of RSpec. Michal Bakowski ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-29 00:40 Message: Please submit your entire spec so we can reproduce this. (what's the definition of valid_employee_attributes)? You're not running with fixtures, so the employees table is not being cleaned between runs. I suspect that you're trying to save a person with an explicit id, and that that's why it's failing the 2nd time. If you run with Test::Unit, I suspect you get the same result. ---------------------------------------------------------------------- Comment By: Michal Bakowski (dr_bonzo) Date: 2006-10-28 22:58 Message: Source of bug found. I started building this spec from scratch: ---8<------------------------------- Employee with validates_uniqueness_of :login (...) context "New Employee" do include EmployeeSpecHelper def setup # important, I also used in in previous case, but not included it in code listing puts "====================" end specify "should have all attributes set" do employee = Employee.new(valid_employee_attributes) employee.employee_group_id = 0 employee.save.should.be true end end ================================8<============ And I have finally located source of this bug. It was this simple 'setup' method (I needed it for debugging (separating debug messages) spec as it does not have 'breakpoint' feature :( ). OMG, my mistake (RTFM): it is not "def setup..." (T::U way) but "setup do..." (RS) How to reproduce bug: I clear the DB. Run this spec (spec .../employee_spec.rb) It passes. There is 1 record in DB Run it once more I get the error: --- Solution I remove 'setup' method from spec Run this spec (spec .../employee_spec.rb) It passes. DB is empty Run it once more And it is ok (spec passed, DB empty) Thanks for motivation, as I returned to Test::Unit after that failure :) Michal Bakowski ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-10-28 19:49 Message: Since you were playing with self.use_transactional_fixtures, you may have created the record when that was set to false. Can you please manually ensure that your database table is empty, set self.use_transactional_fixtures to true and run the spec twice and report back if this still happens? Thanks, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=9465&aid=6375&group_id=797 From noreply at rubyforge.org Sun Oct 29 05:23:18 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 29 Oct 2006 05:23:18 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-5645 ] should_be_empty fails on has_many collections Message-ID: <20061029102318.DF431A970014@rubyforge.org> Bugs item #5645, was opened at 2006-09-06 12:31 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=5645&group_id=797 Category: None Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Jeff Hoffman (wheeledone) Assigned to: Nobody (None) Summary: should_be_empty fails on has_many collections Initial Comment: class Context < ActiveRecord::Base has_many :action_items end class ActionItem < ActiveRecord::Base belongs_to :context end context "A new context" do setup do @context = Context.new end specify "should not have any action items" do @context.action_items.should_be_empty end end NoMethodError in 'A new context should not have any action items' undefined method `empty?' for ActionItem:Class /myproject/config/../vendor/rails/activerecord/lib/active_record/base.rb:1228:in `method_missing' /myproject/config/../vendor/rails/activerecord/lib/active_record/base.rb:1228:in `method_missing' /myproject/config/../vendor/rails/activerecord/lib/active_record/associations/has_many_association.rb:108:in `method_missing' /myproject/config/../vendor/rails/activerecord/lib/active_record/base.rb:942:in `with_scope' /myproject/config/../vendor/rails/activerecord/lib/active_record/associations/has_many_association.rb:98:in `method_missing' ./spec/models/context_spec.rb:13:in `should not have any action items' I tested this on both 1.1.6 and Edge...results were the same with both. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-10-29 10:23 Message: Fixed in 0.7 ---------------------------------------------------------------------- Comment By: Jeff Hoffman (wheeledone) Date: 2006-09-07 13:31 Message: Yes, I am. Want to be on the beta list? :) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-09-07 12:46 Message: action_items? Jeff - are you building a GTD tool? ---------------------------------------------------------------------- Comment By: Jeff Hoffman (wheeledone) Date: 2006-09-06 12:34 Message: Oops, forgot to show the workaround. If I change the expectation to: @context.should_satisfy { |c| c.action_items.empty? } it works fine...and here is a console session showing that my model is functioning: $ ./script/console Loading development environment. >> c = Context.new => #nil, "updated_at"=>nil, "lock_version"=>0, "created_at"=>nil}, @new_record=true> >> c.action_items.empty? => true >> ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=5645&group_id=797 From dchelimsky at gmail.com Sun Oct 29 06:18:20 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 29 Oct 2006 05:18:20 -0600 Subject: [rspec-devel] status of impending release Message-ID: <57c63afe0610290318t5587db1ft3f60aef8a27951c7@mail.gmail.com> Hey all, I had started to make an effort to include integration spec'ing for the rails plugin in the 0.7 release, but that is proving more problematic than I had expected. Definitely solvable, but I don't want it to hang up the release. That said, I am planning at this point to spend the next couple of days tweaking documentation and release 0.7 w/ the trunk more or less as/is (without rails integration specs). There may be a couple of bug fixes and/or refactorings between now and then, but no real feature additions (there is already a TON). All in favor? Thanks, David From lists-rspec at shopwatch.org Sun Oct 29 08:10:09 2006 From: lists-rspec at shopwatch.org (Jay Levitt) Date: Sun, 29 Oct 2006 08:10:09 -0500 Subject: [rspec-devel] status of impending release In-Reply-To: <57c63afe0610290318t5587db1ft3f60aef8a27951c7@mail.gmail.com> References: <57c63afe0610290318t5587db1ft3f60aef8a27951c7@mail.gmail.com> Message-ID: <4544A831.5030204@rubyforge.org> David Chelimsky wrote: > Hey all, > > I had started to make an effort to include integration spec'ing for > the rails plugin in the 0.7 release, but that is proving more > problematic than I had expected. Definitely solvable, but I don't want > it to hang up the release. > > That said, I am planning at this point to spend the next couple of > days tweaking documentation and release 0.7 w/ the trunk more or less > as/is (without rails integration specs). There may be a couple of bug > fixes and/or refactorings between now and then, but no real feature > additions (there is already a TON). > > All in favor? aye... I'm looking forward to integration testing myself, but wouldn't want it to hold up the release. > > Thanks, > David > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From dastels at daveastels.com Sun Oct 29 08:52:19 2006 From: dastels at daveastels.com (Dave Astels) Date: Sun, 29 Oct 2006 09:52:19 -0400 Subject: [rspec-devel] status of impending release In-Reply-To: <57c63afe0610290318t5587db1ft3f60aef8a27951c7@mail.gmail.com> References: <57c63afe0610290318t5587db1ft3f60aef8a27951c7@mail.gmail.com> Message-ID: <69417AA5-AAF9-475A-B601-CAD90EF2A0BA@daveastels.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 29-Oct-06, at 7:18 AM, David Chelimsky wrote: > > That said, I am planning at this point to spend the next couple of > days tweaking documentation and release 0.7 w/ the trunk more or less > as/is (without rails integration specs). There may be a couple of bug > fixes and/or refactorings between now and then, but no real feature > additions (there is already a TON). > > All in favor? > +1 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFFRLITauez/L4x7g4RAobOAKC6tDrEvnN9ojRuT5H+/9FmvHKx5QCeOdET I3gma67PUuXzBTJTwMQbhu4= =JfIj -----END PGP SIGNATURE----- From jeff at jefdean.com Sun Oct 29 15:57:49 2006 From: jeff at jefdean.com (Jeff Dean) Date: Sun, 29 Oct 2006 15:57:49 -0500 Subject: [rspec-devel] what to do next Message-ID: <246e442a0610291257n5af9d5a6jd927cd82d1c76f4e@mail.gmail.com> I'd like to start working on the rspec on rails plugin and I noticed two open feature requests, and I'd like to add support for sending headers along with http requests. https://rubyforge.org/account/login.php seems to be down so I couldn't create an account or register the new feature request. I'll try again later. Is anyone currently working on making scaffold_resource work with rspec? If not, I can put in some time on that. I'd also like to add support for --skip-migrations, which scaffold_resource doesn't currently have. Thanks, Jeff Dean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061029/8a7506b9/attachment.html From aslak.hellesoy at gmail.com Sun Oct 29 17:55:48 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sun, 29 Oct 2006 22:55:48 +0000 Subject: [rspec-devel] what to do next In-Reply-To: <246e442a0610291257n5af9d5a6jd927cd82d1c76f4e@mail.gmail.com> References: <246e442a0610291257n5af9d5a6jd927cd82d1c76f4e@mail.gmail.com> Message-ID: <8d961d900610291455k2d4b817fpdfa85fea3b99c161@mail.gmail.com> On 10/29/06, Jeff Dean wrote: > I'd like to start working on the rspec on rails plugin and I noticed two > open feature requests, and I'd like to add support for sending headers along > with http requests. > > https://rubyforge.org/account/login.php seems to be down > so I couldn't create an account or register the new feature request. I'll > try again later. > > Is anyone currently working on making scaffold_resource work with rspec? Not that I know of. See how the existing generators are done - we'd like to reuse as much as possible from Rails. > If > not, I can put in some time on that. I'd also like to add support for > --skip-migrations, which scaffold_resource doesn't currently have. > That would be great. If you can't get into Rubyforge's tracker, just send patches to this list. Cheers, Aslak > Thanks, > > Jeff Dean > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > From jeff at jefdean.com Sun Oct 29 18:44:32 2006 From: jeff at jefdean.com (Jeff Dean) Date: Sun, 29 Oct 2006 18:44:32 -0500 Subject: [rspec-devel] what to do next In-Reply-To: <8d961d900610291455k2d4b817fpdfa85fea3b99c161@mail.gmail.com> References: <246e442a0610291257n5af9d5a6jd927cd82d1c76f4e@mail.gmail.com> <8d961d900610291455k2d4b817fpdfa85fea3b99c161@mail.gmail.com> Message-ID: <246e442a0610291544u6eaf219en48817d6b0b761b1d@mail.gmail.com> Thanks - I'll start working on the generator. Does the current version build it's own get/post/put/delete/head requests or build off of the rails functional test methods? On 10/29/06, aslak hellesoy wrote: > > On 10/29/06, Jeff Dean wrote: > > I'd like to start working on the rspec on rails plugin and I noticed two > > open feature requests, and I'd like to add support for sending headers > along > > with http requests. > > > > https://rubyforge.org/account/login.php seems to be down > > so I couldn't create an account or register the new feature > request. I'll > > try again later. > > > > Is anyone currently working on making scaffold_resource work with rspec? > > Not that I know of. See how the existing generators are done - we'd > like to reuse as much as possible from Rails. > > > If > > not, I can put in some time on that. I'd also like to add support for > > --skip-migrations, which scaffold_resource doesn't currently have. > > > > That would be great. > > If you can't get into Rubyforge's tracker, just send patches to this list. > > Cheers, > Aslak > > > Thanks, > > > > Jeff Dean > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061029/85a73c79/attachment.html From noreply at rubyforge.org Sun Oct 29 14:22:55 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 29 Oct 2006 14:22:55 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6393 ] [PATCH] rspec_on_rails uses deprecated '@response' instead of the accessor Message-ID: <20061029192255.6CBF0A97002B@rubyforge.org> Patches item #6393, was opened at 2006-10-29 14:22 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6393&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wilson Bilkovich (wilson) Assigned to: Nobody (None) Summary: [PATCH] rspec_on_rails uses deprecated '@response' instead of the accessor Initial Comment: Pretty much what the summary says. This fixes deprecation warnings when running controller specs against edge rails. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6393&group_id=797 From dchelimsky at gmail.com Sun Oct 29 20:46:09 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 29 Oct 2006 20:46:09 -0500 Subject: [rspec-devel] [ rspec-Patches-6393 ] [PATCH] rspec_on_rails uses deprecated '@response' instead of the accessor In-Reply-To: <20061029192255.6CBF0A97002B@rubyforge.org> References: <20061029192255.6CBF0A97002B@rubyforge.org> Message-ID: <57c63afe0610291746r2f9ebe9cn4a361aa1ec352fbc@mail.gmail.com> I can't get to rubyforge right now to reply to this via the tracker - but this is fixed in the trunk and will be released w/ 0.7. On 10/29/06, noreply at rubyforge.org wrote: > Patches item #6393, was opened at 2006-10-29 14:22 > You can respond by visiting: > http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6393&group_id=797 > > Category: None > Group: None > Status: Open > Resolution: None > Priority: 3 > Submitted By: Wilson Bilkovich (wilson) > Assigned to: Nobody (None) > Summary: [PATCH] rspec_on_rails uses deprecated '@response' instead of the accessor > > Initial Comment: > Pretty much what the summary says. This fixes deprecation warnings when running controller specs against edge rails. > > ---------------------------------------------------------------------- > > You can respond by visiting: > http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6393&group_id=797 > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From wilsonb at gmail.com Sun Oct 29 20:47:52 2006 From: wilsonb at gmail.com (Wilson Bilkovich) Date: Sun, 29 Oct 2006 21:47:52 -0400 Subject: [rspec-devel] [ rspec-Patches-6393 ] [PATCH] rspec_on_rails uses deprecated '@response' instead of the accessor In-Reply-To: <20061029192255.6CBF0A97002B@rubyforge.org> References: <20061029192255.6CBF0A97002B@rubyforge.org> Message-ID: On 10/29/06, noreply at rubyforge.org wrote: > Patches item #6393, was opened at 2006-10-29 14:22 > You can respond by visiting: > http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6393&group_id=797 > > Category: None > Group: None > Status: Open > Resolution: None > Priority: 3 > Submitted By: Wilson Bilkovich (wilson) > Assigned to: Nobody (None) > Summary: [PATCH] rspec_on_rails uses deprecated '@response' instead of the accessor > > Initial Comment: > Pretty much what the summary says. This fixes deprecation warnings when running controller specs against edge rails. > > ---------------------------------------------------------------------- > > You can respond by visiting: > http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6393&group_id=797 > _______________________________________________ Right after this, I got a bunch more warnings about @session, etc, etc. This does fix the @response problem, but there are several more to track down. I didn't see any mention of @session in the rspec_on_rails plugin code, so it might be some instance_variable_get magick. From dchelimsky at gmail.com Sun Oct 29 20:49:26 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 29 Oct 2006 20:49:26 -0500 Subject: [rspec-devel] [ rspec-Patches-6393 ] [PATCH] rspec_on_rails uses deprecated '@response' instead of the accessor In-Reply-To: References: <20061029192255.6CBF0A97002B@rubyforge.org> Message-ID: <57c63afe0610291749r46e6dfe2v92126ef52f81508@mail.gmail.com> On 10/29/06, Wilson Bilkovich wrote: > On 10/29/06, noreply at rubyforge.org wrote: > > Patches item #6393, was opened at 2006-10-29 14:22 > > You can respond by visiting: > > http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6393&group_id=797 > > > > Category: None > > Group: None > > Status: Open > > Resolution: None > > Priority: 3 > > Submitted By: Wilson Bilkovich (wilson) > > Assigned to: Nobody (None) > > Summary: [PATCH] rspec_on_rails uses deprecated '@response' instead of the accessor > > > > Initial Comment: > > Pretty much what the summary says. This fixes deprecation warnings when running controller specs against edge rails. > > > > ---------------------------------------------------------------------- > > > > You can respond by visiting: > > http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6393&group_id=797 > > _______________________________________________ > These should all go away in 0.7. > Right after this, I got a bunch more warnings about @session, etc, > etc. This does fix the @response problem, but there are several more > to track down. I didn't see any mention of @session in the > rspec_on_rails plugin code, so it might be some instance_variable_get > magick. > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dchelimsky at gmail.com Sun Oct 29 23:22:43 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 29 Oct 2006 23:22:43 -0500 Subject: [rspec-devel] what to do next In-Reply-To: <246e442a0610291544u6eaf219en48817d6b0b761b1d@mail.gmail.com> References: <246e442a0610291257n5af9d5a6jd927cd82d1c76f4e@mail.gmail.com> <8d961d900610291455k2d4b817fpdfa85fea3b99c161@mail.gmail.com> <246e442a0610291544u6eaf219en48817d6b0b761b1d@mail.gmail.com> Message-ID: <57c63afe0610292022t6e463501v553205b2e980e5ea@mail.gmail.com> On 10/29/06, Jeff Dean wrote: > Thanks - I'll start working on the generator. > > Does the current version build it's own get/post/put/delete/head requests or > build off of the rails functional test methods? Works off the rails functional test methods for the moment. Please make sure you are working w/ the current trunk (we're at revision 992), as the structure of the rails plugin has changed considerably. Thanks, David > > > On 10/29/06, aslak hellesoy wrote: > > On 10/29/06, Jeff Dean wrote: > > > I'd like to start working on the rspec on rails plugin and I noticed two > > > open feature requests, and I'd like to add support for sending headers > along > > > with http requests. > > > > > > https://rubyforge.org/account/login.php seems to be > down > > > so I couldn't create an account or register the new feature request. > I'll > > > try again later. > > > > > > Is anyone currently working on making scaffold_resource work with rspec? > > > > Not that I know of. See how the existing generators are done - we'd > > like to reuse as much as possible from Rails. > > > > > If > > > not, I can put in some time on that. I'd also like to add support for > > > --skip-migrations, which scaffold_resource doesn't currently have. > > > > > > > That would be great. > > > > If you can't get into Rubyforge's tracker, just send patches to this list. > > > > Cheers, > > Aslak > > > > > Thanks, > > > > > > Jeff Dean > > > > > > _______________________________________________ > > > rspec-devel mailing list > > > rspec-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > From jeff at jefdean.com Mon Oct 30 03:06:32 2006 From: jeff at jefdean.com (Jeff Dean) Date: Mon, 30 Oct 2006 03:06:32 -0500 Subject: [rspec-devel] Spec a spec generator Message-ID: <246e442a0610300006n5babb1d1wd22d538fa056d4a5@mail.gmail.com> I just created an rspec_scaffold_resource generator and I've got a few questions about what the next steps are. First, this is a total noob question, but how do I run the specs from rspec/vendor/rspec_on_rails/vendor/plugins/rspec/spec from the command line? I haven't written specs for the generator yet because I don't know how to run them. Second, rspec_scaffold_resource depends on edge rails. Is it safe to assume that if you are running rspec_scaffold_resource that you are already running edge, or should I try to check for it somehow? On a related note - since you can't run it without edge, you need to freeze edge or add an svn:externals property to even try it out. Third, I'm not too experienced with patching, but I assume that the TortosieSVN's "create patch" and specifying all of the new/modified files should do the trick. Is there anything else I should know? Any incompatibilities I should watch out for? And last - I know that the directory structure will change soon, and since the generator creates files I imagine I'd want to test that these files are correctly created. I'd like to write a comprehensive spec, but I'd prefer not to write it twice (if the directory changes will affect the sample rails app). Any thoughts on how to proceed here? Thanks in advance for your time, Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061030/d61c54d5/attachment-0001.html From dchelimsky at gmail.com Mon Oct 30 04:23:41 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 30 Oct 2006 04:23:41 -0500 Subject: [rspec-devel] Spec a spec generator In-Reply-To: <246e442a0610300006n5babb1d1wd22d538fa056d4a5@mail.gmail.com> References: <246e442a0610300006n5babb1d1wd22d538fa056d4a5@mail.gmail.com> Message-ID: <57c63afe0610300123l4d068972h6adc30b9171b29df@mail.gmail.com> On 10/30/06, Jeff Dean wrote: > I just created an rspec_scaffold_resource generator and I've got a few > questions about what the next steps are. > > First, this is a total noob question, but how do I run the specs from > rspec/vendor/rspec_on_rails/vendor/plugins/rspec/spec from > the command line? I haven't written specs for the generator yet because I > don't know how to run them. Assuming you've checked out the source and have all the dependencies, stand in vendor/rspec_on_rails and say "rake spec:plugins" or "../../bin/spec vendor/plugins/rspec/spec". > > Second, rspec_scaffold_resource depends on edge rails. Is it safe to assume > that if you are running rspec_scaffold_resource that you are already running > edge, or should I try to check for it somehow? On a related note - since > you can't run it without edge, you need to freeze edge or add an > svn:externals property to even try it out. This is something I hadn't considered. We don't have any official support policy, and given that nobody working on this does so full time, any such policy would have to take that into account. The most reasonable policy I can think of is that we should do our best to ensuring that any rspec release works w/ the latest rails stable release at the time. This would, obviously, not pertain to edge rails. Maybe some day enough people will use rspec on rails and the rails core team will have the good sense to incorporate this functionality right into rails (you can say-ay-ay I'm a dreamer.....). In the mean time, this does present an interesting dilemma. What if we were to set up the build so that running "rake pre_commit" will run everything but these edge-rails-specific specs against the latest stable rails and fail the build if anything fails, but then run everything including the edge-rails-specific specs and only report if anything fails, but still pass the build? That would keep us progressing without turning edge rails into a bottleneck, but would also keep edge rails constantly on the radar. If that makes sense to everyone, I'm sure we can figure out a way to do it. > Third, I'm not too experienced with patching, but I assume that the > TortosieSVN's "create patch" and specifying all of the new/modified files > should do the trick. Is there anything else I should know? Any > incompatibilities I should watch out for? I've not used TortoiseSVN to create a patch, so someone else will have to comment on this. > And last - I know that the directory structure will change soon, and since > the generator creates files I imagine I'd want to test that these files are > correctly created. I'd like to write a comprehensive spec, but I'd prefer > not to write it twice (if the directory changes will affect the sample rails > app). Any thoughts on how to proceed here? What that is going to look like is totally unknown right now. There are wide reaching implications in our build - for example, almost all of the examples on the website, including those for rspec on rails, get run with "rake pre_commit". This guarantees that the examples actually work, which is an important feature that I'd not be very willing to give up. So the existing example app will need to live somewhere (so we can use it for the documentation), though it is not necessary for it to live in the same directory structure as the plugin code. Also, some of the specs in vendor/rspec_on_rails/vendor/plugins/rspec/spec (which specify the plugin) use controllers and views that are assumed to be where they would normally be in a rails app. In order to move them beneath the plugin dirs, we'd have to override all of the underlying rails mapping mojo. The more I think of that, the less sense it makes to me - BUT, not making that move means that you can't run those specs without having the specified controllers, helpers, views, etc in their natural homes. Kinda sucks. All of that said, I'm not sure where this is leading, so the best advice I can offer is to work w/in the existing directory structure (in trunk) and hope for the best. There's no guarantee any of this will move anywhere, so why let that impede your work now? > Thanks in advance for your time, And for yours! Cheers, David > > Jeff > > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > From noreply at rubyforge.org Mon Oct 30 02:51:44 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 Oct 2006 02:51:44 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6396 ] Disabled Specifications and a Yellow build Message-ID: <20061030075144.8B5EB524100F@rubyforge.org> Feature Requests item #6396, was opened at 2006-10-30 02:51 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6396&group_id=797 Category: runner module Group: None Status: Open Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: Disabled Specifications and a Yellow build Initial Comment: Add a method that denotes a specification is disabled and causes a yellow build. For example: disable_specify "should support disabled specifications" do end This will be helpful in writing a spec before the feature is implemented. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6396&group_id=797 From noreply at rubyforge.org Mon Oct 30 02:57:57 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 Oct 2006 02:57:57 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6396 ] Disabled Specifications and a Yellow build Message-ID: <20061030075758.0BBDE5241017@rubyforge.org> Feature Requests item #6396, was opened at 2006-10-29 23:51 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6396&group_id=797 Category: runner module Group: None Status: Open Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: Disabled Specifications and a Yellow build Initial Comment: Add a method that denotes a specification is disabled and causes a yellow build. For example: disable_specify "should support disabled specifications" do end This will be helpful in writing a spec before the feature is implemented. ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2006-10-29 23:57 Message: I submitted this. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6396&group_id=797 From noreply at rubyforge.org Mon Oct 30 04:57:46 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 Oct 2006 04:57:46 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6396 ] Disabled Specifications and a Yellow build Message-ID: <20061030095747.08830A970014@rubyforge.org> Feature Requests item #6396, was opened at 2006-10-30 07:51 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6396&group_id=797 Category: runner module Group: None Status: Open Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: Disabled Specifications and a Yellow build Initial Comment: Add a method that denotes a specification is disabled and causes a yellow build. For example: disable_specify "should support disabled specifications" do end This will be helpful in writing a spec before the feature is implemented. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-10-30 09:57 Message: Writing an entire specify block before a feature is implemented is not what BDD is about. It goes against the red/green/refactor cycle of TDD, which sits at the heart of BDD. For what it's worth, there is a similar feature in NUnit. I don't believe that I've ever seen it used to allow tests to be ignored in advance of implementation. I've only ever seen it used to ignore existing tests that had been passing and were now failing. Worse, I've seen this cause yellow to become the new green (i.e. an acceptable state for commits and sometimes even releases). Absolutely vile. That said, making decisions about behaviour in advance of implementation is very much aligned w/ BDD, even TDD. What would you think about something like this: implement "should support placeholders for yet to exist specs" This would not accept a block. In fact it would raise if you try to give it one. This way you could write placeholders for specs you know you want, but not allow you to put any code in them. Then there could be a command line option that allows you to report on yet-to-implement specs. Of course, if you insist on violating one of the most basic principles of BDD, you can write up your spec code and comment it out. The commented code would be in a logical place, but the tool would not be condoning the practice. Thoughts? David ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2006-10-30 07:57 Message: I submitted this. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6396&group_id=797 From aslak.hellesoy at gmail.com Mon Oct 30 08:43:55 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Mon, 30 Oct 2006 14:43:55 +0100 Subject: [rspec-devel] Spec a spec generator In-Reply-To: <57c63afe0610300123l4d068972h6adc30b9171b29df@mail.gmail.com> References: <246e442a0610300006n5babb1d1wd22d538fa056d4a5@mail.gmail.com> <57c63afe0610300123l4d068972h6adc30b9171b29df@mail.gmail.com> Message-ID: <8d961d900610300543o57e87bd3r4828f1347f5fdc82@mail.gmail.com> On 10/30/06, David Chelimsky wrote: > On 10/30/06, Jeff Dean wrote: > > I just created an rspec_scaffold_resource generator and I've got a few > > questions about what the next steps are. > > > > First, this is a total noob question, but how do I run the specs from > > rspec/vendor/rspec_on_rails/vendor/plugins/rspec/spec from > > the command line? I haven't written specs for the generator yet because I > > don't know how to run them. > > Assuming you've checked out the source and have all the dependencies, > stand in vendor/rspec_on_rails and say "rake spec:plugins" or > "../../bin/spec vendor/plugins/rspec/spec". > > > > > Second, rspec_scaffold_resource depends on edge rails. Is it safe to assume > > that if you are running rspec_scaffold_resource that you are already running > > edge, or should I try to check for it somehow? On a related note - since > > you can't run it without edge, you need to freeze edge or add an > > svn:externals property to even try it out. > For now, just assume edge rails is available. > This is something I hadn't considered. We don't have any official > support policy, and given that nobody working on this does so full > time, any such policy would have to take that into account. The most > reasonable policy I can think of is that we should do our best to > ensuring that any rspec release works w/ the latest rails stable > release at the time. This would, obviously, not pertain to edge rails. > Maybe some day enough people will use rspec on rails and the rails > core team will have the good sense to incorporate this functionality > right into rails (you can say-ay-ay I'm a dreamer.....). > > In the mean time, this does present an interesting dilemma. What if we > were to set up the build so that running "rake pre_commit" will run > everything but these edge-rails-specific specs against the latest > stable rails and fail the build if anything fails, but then run > everything including the edge-rails-specific specs and only report if > anything fails, but still pass the build? That would keep us > progressing without turning edge rails into a bottleneck, but would > also keep edge rails constantly on the radar. > > If that makes sense to everyone, I'm sure we can figure out a way to do it. > A script that specifies an array of svn tags and trunk. E.g. ['tags/1.1.6', 'trunk'] We'd loop through this array and run rake spec for all of them. Each spec could have its body in an if block a la: if(RAILS_VERSION > 1.1.6) specify "something that should only work on edge" do ... end end > > Third, I'm not too experienced with patching, but I assume that the > > TortosieSVN's "create patch" and specifying all of the new/modified files > > should do the trick. Is there anything else I should know? Any > > incompatibilities I should watch out for? > > I've not used TortoiseSVN to create a patch, so someone else will have > to comment on this. > create patch should work. Make sure to attach entirely new files too. At rubyforge, add a comment to your patches, so we can distinguish older from newer patches. > > And last - I know that the directory structure will change soon, and since > > the generator creates files I imagine I'd want to test that these files are > > correctly created. I'd like to write a comprehensive spec, but I'd prefer > > not to write it twice (if the directory changes will affect the sample rails > > app). Any thoughts on how to proceed here? > > What that is going to look like is totally unknown right now. There > are wide reaching implications in our build - for example, almost all > of the examples on the website, including those for rspec on rails, > get run with "rake pre_commit". This guarantees that the examples > actually work, which is an important feature that I'd not be very > willing to give up. So the existing example app will need to live > somewhere (so we can use it for the documentation), though it is not > necessary for it to live in the same directory structure as the plugin > code. > > Also, some of the specs in > vendor/rspec_on_rails/vendor/plugins/rspec/spec (which specify the > plugin) use controllers and views that are assumed to be where they > would normally be in a rails app. In order to move them beneath the > plugin dirs, we'd have to override all of the underlying rails mapping > mojo. The more I think of that, the less sense it makes to me - BUT, > not making that move means that you can't run those specs without > having the specified controllers, helpers, views, etc in their natural > homes. Kinda sucks. > > All of that said, I'm not sure where this is leading, so the best > advice I can offer is to work w/in the existing directory structure > (in trunk) and hope for the best. There's no guarantee any of this > will move anywhere, so why let that impede your work now? > > > Thanks in advance for your time, > > And for yours! > > Cheers, > David > > > > > Jeff > > > > > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From wilsonb at gmail.com Mon Oct 30 10:34:45 2006 From: wilsonb at gmail.com (Wilson Bilkovich) Date: Mon, 30 Oct 2006 10:34:45 -0500 Subject: [rspec-devel] Spec a spec generator In-Reply-To: <57c63afe0610300123l4d068972h6adc30b9171b29df@mail.gmail.com> References: <246e442a0610300006n5babb1d1wd22d538fa056d4a5@mail.gmail.com> <57c63afe0610300123l4d068972h6adc30b9171b29df@mail.gmail.com> Message-ID: On 10/30/06, David Chelimsky wrote: > On 10/30/06, Jeff Dean wrote: > > Third, I'm not too experienced with patching, but I assume that the > > TortosieSVN's "create patch" and specifying all of the new/modified files > > should do the trick. Is there anything else I should know? Any > > incompatibilities I should watch out for? > Yep. That's all you need to do. Make sure you're working with the latest revision, right-click, 'Create Patch', etc. From jeff at jefdean.com Mon Oct 30 16:56:59 2006 From: jeff at jefdean.com (Jeff Dean) Date: Mon, 30 Oct 2006 16:56:59 -0500 Subject: [rspec-devel] Spec a spec generator In-Reply-To: <8d961d900610300543o57e87bd3r4828f1347f5fdc82@mail.gmail.com> References: <246e442a0610300006n5babb1d1wd22d538fa056d4a5@mail.gmail.com> <57c63afe0610300123l4d068972h6adc30b9171b29df@mail.gmail.com> <8d961d900610300543o57e87bd3r4828f1347f5fdc82@mail.gmail.com> Message-ID: <246e442a0610301356x3e965c0cxe36384b31f757b20@mail.gmail.com> I just tried to run rake spec:plugins from trunk and got the following error message. I have the 0.6.4 gem installed. D:\rails\rspec\vendor\rspec_on_rails>rake spec:plugins (in D:/rails/rspec/vendor/rspec_on_rails) c:/ruby/bin/ruby -I"D:/rails/rspec/lib" "D:/rails/rspec/bin/spec" "vendor/plugins/rspec/spec/context_factory_spec.rb" "vendor/plugins/rspec/spec/controller_isolation_spec.rb" "vendor/plugins/rspec/spe c/opts_merger_spec.rb" "vendor/plugins/rspec/spec/expectations/should_be_spec.rb" "vendor/plugins/rspec/spec/expectations/should_have_rjs_spec.rb" "vendor/plugins/rspec/spec/expectations/should_have_t ag_spec.rb" "vendor/plugins/rspec/spec/expectations/should_not_have_rjs_spec.rb" "vendor/plugins/rspec/spec/expectations/should_not_have_tag_spec.rb" "vendor/plugins/rspec/spec/expectations/should_not _render_rjs_spec.rb" "vendor/plugins/rspec/spec/expectations/should_render_rjs_spec.rb" "vendor/plugins/rspec/spec/expectations/should_render_spec.rb" "vendor/plugins/rspec/spec/generators/rspec_resou rce_scaffold_spec.rb" c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require': no such file to load -- controller_mixin (MissingSourceFile) from c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require' from D:/rails/rspec/vendor/rspec_on_rails/config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:400:in `require' from ./vendor/plugins/rspec/spec/../../../../spec/spec_helper.rb:3 from c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require' from ./vendor/plugins/rspec/spec/spec_helper.rb:1 from c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require' from ./vendor/plugins/rspec/spec/context_factory_spec.rb:1 from c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require' from D:/rails/rspec/bin/spec:14 from D:/rails/rspec/bin/spec:8 rake aborted! Command failed with status (1): [c:/ruby/bin/ruby -I"D:/rails/rspec/lib" "D...] Do I have to uninstall the gem to make this work? On 10/30/06, aslak hellesoy wrote: > > On 10/30/06, David Chelimsky wrote: > > On 10/30/06, Jeff Dean wrote: > > > I just created an rspec_scaffold_resource generator and I've got a few > > > questions about what the next steps are. > > > > > > First, this is a total noob question, but how do I run the specs from > > > rspec/vendor/rspec_on_rails/vendor/plugins/rspec/spec from > > > the command line? I haven't written specs for the generator yet > because I > > > don't know how to run them. > > > > Assuming you've checked out the source and have all the dependencies, > > stand in vendor/rspec_on_rails and say "rake spec:plugins" or > > "../../bin/spec vendor/plugins/rspec/spec". > > > > > > > > Second, rspec_scaffold_resource depends on edge rails. Is it safe to > assume > > > that if you are running rspec_scaffold_resource that you are already > running > > > edge, or should I try to check for it somehow? On a related note - > since > > > you can't run it without edge, you need to freeze edge or add an > > > svn:externals property to even try it out. > > > > For now, just assume edge rails is available. > > > This is something I hadn't considered. We don't have any official > > support policy, and given that nobody working on this does so full > > time, any such policy would have to take that into account. The most > > reasonable policy I can think of is that we should do our best to > > ensuring that any rspec release works w/ the latest rails stable > > release at the time. This would, obviously, not pertain to edge rails. > > Maybe some day enough people will use rspec on rails and the rails > > core team will have the good sense to incorporate this functionality > > right into rails (you can say-ay-ay I'm a dreamer.....). > > > > In the mean time, this does present an interesting dilemma. What if we > > were to set up the build so that running "rake pre_commit" will run > > everything but these edge-rails-specific specs against the latest > > stable rails and fail the build if anything fails, but then run > > everything including the edge-rails-specific specs and only report if > > anything fails, but still pass the build? That would keep us > > progressing without turning edge rails into a bottleneck, but would > > also keep edge rails constantly on the radar. > > > > If that makes sense to everyone, I'm sure we can figure out a way to do > it. > > > > A script that specifies an array of svn tags and trunk. E.g. > ['tags/1.1.6', 'trunk'] > We'd loop through this array and run rake spec for all of them. > > Each spec could have its body in an if block a la: > > if(RAILS_VERSION > 1.1.6) > specify "something that should only work on edge" do > ... > end > end > > > > Third, I'm not too experienced with patching, but I assume that the > > > TortosieSVN's "create patch" and specifying all of the new/modified > files > > > should do the trick. Is there anything else I should know? Any > > > incompatibilities I should watch out for? > > > > I've not used TortoiseSVN to create a patch, so someone else will have > > to comment on this. > > > > create patch should work. Make sure to attach entirely new files too. > At rubyforge, add a comment to your patches, so we can distinguish > older from newer patches. > > > > And last - I know that the directory structure will change soon, and > since > > > the generator creates files I imagine I'd want to test that these > files are > > > correctly created. I'd like to write a comprehensive spec, but I'd > prefer > > > not to write it twice (if the directory changes will affect the sample > rails > > > app). Any thoughts on how to proceed here? > > > > What that is going to look like is totally unknown right now. There > > are wide reaching implications in our build - for example, almost all > > of the examples on the website, including those for rspec on rails, > > get run with "rake pre_commit". This guarantees that the examples > > actually work, which is an important feature that I'd not be very > > willing to give up. So the existing example app will need to live > > somewhere (so we can use it for the documentation), though it is not > > necessary for it to live in the same directory structure as the plugin > > code. > > > > Also, some of the specs in > > vendor/rspec_on_rails/vendor/plugins/rspec/spec (which specify the > > plugin) use controllers and views that are assumed to be where they > > would normally be in a rails app. In order to move them beneath the > > plugin dirs, we'd have to override all of the underlying rails mapping > > mojo. The more I think of that, the less sense it makes to me - BUT, > > not making that move means that you can't run those specs without > > having the specified controllers, helpers, views, etc in their natural > > homes. Kinda sucks. > > > > All of that said, I'm not sure where this is leading, so the best > > advice I can offer is to work w/in the existing directory structure > > (in trunk) and hope for the best. There's no guarantee any of this > > will move anywhere, so why let that impede your work now? > > > > > Thanks in advance for your time, > > > > And for yours! > > > > Cheers, > > David > > > > > > > > Jeff > > > > > > > > > > > > _______________________________________________ > > > rspec-devel mailing list > > > rspec-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061030/b216a785/attachment-0001.html From aslak.hellesoy at gmail.com Mon Oct 30 18:13:31 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Tue, 31 Oct 2006 01:13:31 +0200 Subject: [rspec-devel] Spec a spec generator In-Reply-To: <246e442a0610301356x3e965c0cxe36384b31f757b20@mail.gmail.com> References: <246e442a0610300006n5babb1d1wd22d538fa056d4a5@mail.gmail.com> <57c63afe0610300123l4d068972h6adc30b9171b29df@mail.gmail.com> <8d961d900610300543o57e87bd3r4828f1347f5fdc82@mail.gmail.com> <246e442a0610301356x3e965c0cxe36384b31f757b20@mail.gmail.com> Message-ID: <8d961d900610301513m42cb1984pb843b919432a2dc4@mail.gmail.com> On 10/30/06, Jeff Dean wrote: > I just tried to run rake spec:plugins from trunk and got the following error > message. I have the 0.6.4 gem installed. > > D:\rails\rspec\vendor\rspec_on_rails>rake spec:plugins > (in D:/rails/rspec/vendor/rspec_on_rails) > c:/ruby/bin/ruby -I"D:/rails/rspec/lib" "D:/rails/rspec/bin/spec" > "vendor/plugins/rspec/spec/context_factory_spec.rb" > "vendor/plugins/rspec/spec/controller_isolation_spec.rb" > "vendor/plugins/rspec/spe > c/opts_merger_spec.rb" > "vendor/plugins/rspec/spec/expectations/should_be_spec.rb" > "vendor/plugins/rspec/spec/expectations/should_have_rjs_spec.rb" > "vendor/plugins/rspec/spec/expectations/should_have_t > ag_spec.rb" > "vendor/plugins/rspec/spec/expectations/should_not_have_rjs_spec.rb" > "vendor/plugins/rspec/spec/expectations/should_not_have_tag_spec.rb" > "vendor/plugins/rspec/spec/expectations/should_not > _render_rjs_spec.rb" > "vendor/plugins/rspec/spec/expectations/should_render_rjs_spec.rb" > "vendor/plugins/rspec/spec/expectations/should_render_spec.rb" > "vendor/plugins/rspec/spec/generators/rspec_resou > rce_scaffold_spec.rb" > c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > `gem_original_require': no such file to load -- controller_mixin > (MissingSourceFile) > from > c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > `require' > from > D:/rails/rspec/vendor/rspec_on_rails/config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:400:in > `require' > from > ./vendor/plugins/rspec/spec/../../../../spec/spec_helper.rb:3 > from > c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > `require' > from ./vendor/plugins/rspec/spec/spec_helper.rb:1 > from > c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > `require' > from > ./vendor/plugins/rspec/spec/context_factory_spec.rb:1 > from > c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > `require' > from D:/rails/rspec/bin/spec:14 > from D:/rails/rspec/bin/spec:8 > rake aborted! > Command failed with status (1): [c:/ruby/bin/ruby -I"D:/rails/rspec/lib" > "D...] > > Do I have to uninstall the gem to make this work? > No, but you have to re-bootstrap the rails project by first running: ruby script/generate rspec Aslak > > > > On 10/30/06, aslak hellesoy wrote: > > On 10/30/06, David Chelimsky wrote: > > > On 10/30/06, Jeff Dean wrote: > > > > I just created an rspec_scaffold_resource generator and I've got a few > > > > questions about what the next steps are. > > > > > > > > First, this is a total noob question, but how do I run the specs from > > > > rspec/vendor/rspec_on_rails/vendor/plugins/rspec/spec > from > > > > the command line? I haven't written specs for the generator yet > because I > > > > don't know how to run them. > > > > > > Assuming you've checked out the source and have all the dependencies, > > > stand in vendor/rspec_on_rails and say "rake spec:plugins" or > > > "../../bin/spec vendor/plugins/rspec/spec". > > > > > > > > > > > Second, rspec_scaffold_resource depends on edge rails. Is it safe to > assume > > > > that if you are running rspec_scaffold_resource that you are already > running > > > > edge, or should I try to check for it somehow? On a related note - > since > > > > you can't run it without edge, you need to freeze edge or add an > > > > svn:externals property to even try it out. > > > > > > > For now, just assume edge rails is available. > > > > > This is something I hadn't considered. We don't have any official > > > support policy, and given that nobody working on this does so full > > > time, any such policy would have to take that into account. The most > > > reasonable policy I can think of is that we should do our best to > > > ensuring that any rspec release works w/ the latest rails stable > > > release at the time. This would, obviously, not pertain to edge rails. > > > Maybe some day enough people will use rspec on rails and the rails > > > core team will have the good sense to incorporate this functionality > > > right into rails (you can say-ay-ay I'm a dreamer.....). > > > > > > In the mean time, this does present an interesting dilemma. What if we > > > were to set up the build so that running "rake pre_commit" will run > > > everything but these edge-rails-specific specs against the latest > > > stable rails and fail the build if anything fails, but then run > > > everything including the edge-rails-specific specs and only report if > > > anything fails, but still pass the build? That would keep us > > > progressing without turning edge rails into a bottleneck, but would > > > also keep edge rails constantly on the radar. > > > > > > If that makes sense to everyone, I'm sure we can figure out a way to do > it. > > > > > > > A script that specifies an array of svn tags and trunk. E.g. > > ['tags/1.1.6', 'trunk'] > > We'd loop through this array and run rake spec for all of them. > > > > Each spec could have its body in an if block a la: > > > > if(RAILS_VERSION > 1.1.6) > > specify "something that should only work on edge" do > > ... > > end > > end > > > > > > Third, I'm not too experienced with patching, but I assume that the > > > > TortosieSVN's "create patch" and specifying all of the new/modified > files > > > > should do the trick. Is there anything else I should know? Any > > > > incompatibilities I should watch out for? > > > > > > I've not used TortoiseSVN to create a patch, so someone else will have > > > to comment on this. > > > > > > > create patch should work. Make sure to attach entirely new files too. > > At rubyforge, add a comment to your patches, so we can distinguish > > older from newer patches. > > > > > > And last - I know that the directory structure will change soon, and > since > > > > the generator creates files I imagine I'd want to test that these > files are > > > > correctly created. I'd like to write a comprehensive spec, but I'd > prefer > > > > not to write it twice (if the directory changes will affect the sample > rails > > > > app). Any thoughts on how to proceed here? > > > > > > What that is going to look like is totally unknown right now. There > > > are wide reaching implications in our build - for example, almost all > > > of the examples on the website, including those for rspec on rails, > > > get run with "rake pre_commit". This guarantees that the examples > > > actually work, which is an important feature that I'd not be very > > > willing to give up. So the existing example app will need to live > > > somewhere (so we can use it for the documentation), though it is not > > > necessary for it to live in the same directory structure as the plugin > > > code. > > > > > > Also, some of the specs in > > > vendor/rspec_on_rails/vendor/plugins/rspec/spec (which > specify the > > > plugin) use controllers and views that are assumed to be where they > > > would normally be in a rails app. In order to move them beneath the > > > plugin dirs, we'd have to override all of the underlying rails mapping > > > mojo. The more I think of that, the less sense it makes to me - BUT, > > > not making that move means that you can't run those specs without > > > having the specified controllers, helpers, views, etc in their natural > > > homes. Kinda sucks. > > > > > > All of that said, I'm not sure where this is leading, so the best > > > advice I can offer is to work w/in the existing directory structure > > > (in trunk) and hope for the best. There's no guarantee any of this > > > will move anywhere, so why let that impede your work now? > > > > > > > Thanks in advance for your time, > > > > > > And for yours! > > > > > > Cheers, > > > David > > > > > > > > > > > Jeff > > > > > > > > > > > > > > > > _______________________________________________ > > > > rspec-devel mailing list > > > > rspec-devel at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > _______________________________________________ > > > rspec-devel mailing list > > > rspec-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > From undees at gmail.com Mon Oct 30 19:37:05 2006 From: undees at gmail.com (Ian Dees) Date: Mon, 30 Oct 2006 16:37:05 -0800 Subject: [rspec-devel] Wider context for RSpec: GUI testing? Message-ID: Hi, all. I love RSpec's ease of expressing an author's desired behavior for software. That got me thinking about a little wider context (pun unintended) for the meaning of "behavior." It seems like the sweet spot for RSpec is unit testing of Ruby classes (perhaps including Rails models and controllers). But here in the office, we're also beginning to find it useful for specifying GUI behavior. Of course, now that we're outside the original BDD roots of RSpec, there are some philosophical questions, many of which boil down to, "What's the best way of selectively enabling/disabling certain tests?" where "best" means, "most RSpec-like?" Let me give you two examples: 1) For localized applications, some tests might be written cleverly enough to work in _any_ language build of the software, while other tests might be language-specific (maybe they depend on a GUI element having a certain caption, and its identity can't be deduced by any other method). 2) Some GUI tests might require at least partial manual intervention; it would be nice to skip these tests when running an overnight, batch-mode test. I can imagine a few different approaches in RSpec: 1) I could separate the tests into different files by my selection criteria: put the English-only tests in their own file, or put the partially manual tests in their own file. The main downside here is that sometimes the most logical way to group tests isn't necessarily by language or degree of automation. 2) I could extend RSpec (thanks, Ruby!) to allow me to specify optional criteria for a context, something like: context "The Borfin", :interactive => :true do specify "should not go shlump after Mr. Bix un-shlumps it" do # drive the GUI and maybe prompt the tester to do physical stuff end end 3) Like #2 above, but for individual specifications instead of contexts. I lean toward #2, but I wanted to bounce my question off the RSpec devels, since the list archives reveal that you have been thinking a great deal about the semantics of tests. What I _don't_ want to do is pollute RSpec with a bunch of GUI testing cruft. It would be nice to use RSpec in this new domain without compromising its simplicity in its primary domain. Again, though, that's where Ruby's open classes sure come in handy. Thanks in advance for your thoughts. Sincerely, Ian Dees From jeff at jefdean.com Mon Oct 30 20:02:37 2006 From: jeff at jefdean.com (Jeff Dean) Date: Mon, 30 Oct 2006 20:02:37 -0500 Subject: [rspec-devel] Spec a spec generator In-Reply-To: <8d961d900610301513m42cb1984pb843b919432a2dc4@mail.gmail.com> References: <246e442a0610300006n5babb1d1wd22d538fa056d4a5@mail.gmail.com> <57c63afe0610300123l4d068972h6adc30b9171b29df@mail.gmail.com> <8d961d900610300543o57e87bd3r4828f1347f5fdc82@mail.gmail.com> <246e442a0610301356x3e965c0cxe36384b31f757b20@mail.gmail.com> <8d961d900610301513m42cb1984pb843b919432a2dc4@mail.gmail.com> Message-ID: <246e442a0610301702l64446cf2p6f99e59836e7de63@mail.gmail.com> "ruby script/generate rspec" did the trick for getting the specs to start running, but now I'm getting an error and after looking through each of the files, I still can't figure out what the problem is. D:/rails/rspec/vendor/rspec_on_rails/vendor/plugins/rspec/lib/extensions/test/rails.rb line 1 is: - require 'test/rails' This seems to be trying to require itself and I don't know if that is correct or if it should be pointing to somewhere else. I'll keep looking through this, and any help would be appreciated. Here's the error message: C:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require': no such file to load -- test/rails (MissingSourceFile) from C:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require' from D:/rails/rspec/vendor/rspec_on_rails/config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:400:in `require' from D:/rails/rspec/vendor/rspec_on_rails/vendor/plugins/rspec/lib/extensions/test/rails.rb:1 from C:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require' from D:/rails/rspec/vendor/rspec_on_rails/config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:400:in `require' from D:/rails/rspec/vendor/rspec_on_rails/config/../vendor/plugins/rspec/lib/rspec_on_rails.rb:16 from C:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require' from D:/rails/rspec/vendor/rspec_on_rails/config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:400:in `require' from ./vendor/plugins/rspec/spec/../../../../spec/spec_helper.rb:3 from C:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require' from ./vendor/plugins/rspec/spec/spec_helper.rb:1 from C:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require' from ./vendor/plugins/rspec/spec/context_factory_spec.rb:1 from C:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require' from D:/rails/rspec/bin/spec:14 from D:/rails/rspec/bin/spec:8 Jeff On 10/30/06, aslak hellesoy wrote: > > On 10/30/06, Jeff Dean wrote: > > I just tried to run rake spec:plugins from trunk and got the following > error > > message. I have the 0.6.4 gem installed. > > > > D:\rails\rspec\vendor\rspec_on_rails>rake spec:plugins > > (in D:/rails/rspec/vendor/rspec_on_rails) > > c:/ruby/bin/ruby -I"D:/rails/rspec/lib" "D:/rails/rspec/bin/spec" > > "vendor/plugins/rspec/spec/context_factory_spec.rb" > > "vendor/plugins/rspec/spec/controller_isolation_spec.rb" > > "vendor/plugins/rspec/spe > > c/opts_merger_spec.rb" > > "vendor/plugins/rspec/spec/expectations/should_be_spec.rb" > > "vendor/plugins/rspec/spec/expectations/should_have_rjs_spec.rb" > > "vendor/plugins/rspec/spec/expectations/should_have_t > > ag_spec.rb" > > "vendor/plugins/rspec/spec/expectations/should_not_have_rjs_spec.rb" > > "vendor/plugins/rspec/spec/expectations/should_not_have_tag_spec.rb" > > "vendor/plugins/rspec/spec/expectations/should_not > > _render_rjs_spec.rb" > > "vendor/plugins/rspec/spec/expectations/should_render_rjs_spec.rb" > > "vendor/plugins/rspec/spec/expectations/should_render_spec.rb" > > "vendor/plugins/rspec/spec/generators/rspec_resou > > rce_scaffold_spec.rb" > > c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > `gem_original_require': no such file to load -- controller_mixin > > (MissingSourceFile) > > from > > c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > `require' > > from > > > D:/rails/rspec/vendor/rspec_on_rails/config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:400:in > > `require' > > from > > ./vendor/plugins/rspec/spec/../../../../spec/spec_helper.rb:3 > > from > > c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > `require' > > from ./vendor/plugins/rspec/spec/spec_helper.rb:1 > > from > > c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > `require' > > from > > ./vendor/plugins/rspec/spec/context_factory_spec.rb:1 > > from > > c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > `require' > > from D:/rails/rspec/bin/spec:14 > > from D:/rails/rspec/bin/spec:8 > > rake aborted! > > Command failed with status (1): [c:/ruby/bin/ruby -I"D:/rails/rspec/lib" > > "D...] > > > > Do I have to uninstall the gem to make this work? > > > > No, but you have to re-bootstrap the rails project by first running: > > ruby script/generate rspec > > Aslak > > > > > > > > > On 10/30/06, aslak hellesoy wrote: > > > On 10/30/06, David Chelimsky wrote: > > > > On 10/30/06, Jeff Dean wrote: > > > > > I just created an rspec_scaffold_resource generator and I've got a > few > > > > > questions about what the next steps are. > > > > > > > > > > First, this is a total noob question, but how do I run the specs > from > > > > > rspec/vendor/rspec_on_rails/vendor/plugins/rspec/spec > > from > > > > > the command line? I haven't written specs for the generator yet > > because I > > > > > don't know how to run them. > > > > > > > > Assuming you've checked out the source and have all the > dependencies, > > > > stand in vendor/rspec_on_rails and say "rake spec:plugins" or > > > > "../../bin/spec vendor/plugins/rspec/spec". > > > > > > > > > > > > > > Second, rspec_scaffold_resource depends on edge rails. Is it safe > to > > assume > > > > > that if you are running rspec_scaffold_resource that you are > already > > running > > > > > edge, or should I try to check for it somehow? On a related note > - > > since > > > > > you can't run it without edge, you need to freeze edge or add an > > > > > svn:externals property to even try it out. > > > > > > > > > > For now, just assume edge rails is available. > > > > > > > This is something I hadn't considered. We don't have any official > > > > support policy, and given that nobody working on this does so full > > > > time, any such policy would have to take that into account. The most > > > > reasonable policy I can think of is that we should do our best to > > > > ensuring that any rspec release works w/ the latest rails stable > > > > release at the time. This would, obviously, not pertain to edge > rails. > > > > Maybe some day enough people will use rspec on rails and the rails > > > > core team will have the good sense to incorporate this functionality > > > > right into rails (you can say-ay-ay I'm a dreamer.....). > > > > > > > > In the mean time, this does present an interesting dilemma. What if > we > > > > were to set up the build so that running "rake pre_commit" will run > > > > everything but these edge-rails-specific specs against the latest > > > > stable rails and fail the build if anything fails, but then run > > > > everything including the edge-rails-specific specs and only report > if > > > > anything fails, but still pass the build? That would keep us > > > > progressing without turning edge rails into a bottleneck, but would > > > > also keep edge rails constantly on the radar. > > > > > > > > If that makes sense to everyone, I'm sure we can figure out a way to > do > > it. > > > > > > > > > > A script that specifies an array of svn tags and trunk. E.g. > > > ['tags/1.1.6', 'trunk'] > > > We'd loop through this array and run rake spec for all of them. > > > > > > Each spec could have its body in an if block a la: > > > > > > if(RAILS_VERSION > 1.1.6) > > > specify "something that should only work on edge" do > > > ... > > > end > > > end > > > > > > > > Third, I'm not too experienced with patching, but I assume that > the > > > > > TortosieSVN's "create patch" and specifying all of the > new/modified > > files > > > > > should do the trick. Is there anything else I should know? Any > > > > > incompatibilities I should watch out for? > > > > > > > > I've not used TortoiseSVN to create a patch, so someone else will > have > > > > to comment on this. > > > > > > > > > > create patch should work. Make sure to attach entirely new files too. > > > At rubyforge, add a comment to your patches, so we can distinguish > > > older from newer patches. > > > > > > > > And last - I know that the directory structure will change soon, > and > > since > > > > > the generator creates files I imagine I'd want to test that these > > files are > > > > > correctly created. I'd like to write a comprehensive spec, but > I'd > > prefer > > > > > not to write it twice (if the directory changes will affect the > sample > > rails > > > > > app). Any thoughts on how to proceed here? > > > > > > > > What that is going to look like is totally unknown right now. There > > > > are wide reaching implications in our build - for example, almost > all > > > > of the examples on the website, including those for rspec on rails, > > > > get run with "rake pre_commit". This guarantees that the examples > > > > actually work, which is an important feature that I'd not be very > > > > willing to give up. So the existing example app will need to live > > > > somewhere (so we can use it for the documentation), though it is not > > > > necessary for it to live in the same directory structure as the > plugin > > > > code. > > > > > > > > Also, some of the specs in > > > > vendor/rspec_on_rails/vendor/plugins/rspec/spec (which > > specify the > > > > plugin) use controllers and views that are assumed to be where they > > > > would normally be in a rails app. In order to move them beneath the > > > > plugin dirs, we'd have to override all of the underlying rails > mapping > > > > mojo. The more I think of that, the less sense it makes to me - BUT, > > > > not making that move means that you can't run those specs without > > > > having the specified controllers, helpers, views, etc in their > natural > > > > homes. Kinda sucks. > > > > > > > > All of that said, I'm not sure where this is leading, so the best > > > > advice I can offer is to work w/in the existing directory structure > > > > (in trunk) and hope for the best. There's no guarantee any of this > > > > will move anywhere, so why let that impede your work now? > > > > > > > > > Thanks in advance for your time, > > > > > > > > And for yours! > > > > > > > > Cheers, > > > > David > > > > > > > > > > > > > > Jeff > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > rspec-devel mailing list > > > > > rspec-devel at rubyforge.org > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > > _______________________________________________ > > > > rspec-devel mailing list > > > > rspec-devel at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > _______________________________________________ > > > rspec-devel mailing list > > > rspec-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061030/92b9019a/attachment-0001.html From brian.takita at gmail.com Mon Oct 30 20:10:00 2006 From: brian.takita at gmail.com (Brian Takita) Date: Mon, 30 Oct 2006 17:10:00 -0800 Subject: [rspec-devel] Fwd: [ rspec-Feature Requests-6396 ] Disabled Specifications and a Yellow build In-Reply-To: <20061030075758.0BBDE5241017@rubyforge.org> References: <20061030075758.0BBDE5241017@rubyforge.org> Message-ID: <1d7ddd110610301710i54ec52b2kad2056c3a8064215@mail.gmail.com> If you don't mind I would like to move this discussion to the mailing list because it is easier to read. I'm thinking a block would be useful because of bug #4690 has a spec that exposes the bug. The bug is in the system but there is no corresponding spec checked in. One has to go to the bug report to get the spec. This seems like a disconnect between the bug report and the specs. Also, there are times where I would like to run only one spec, because I have some print statements in the code. I can comment out the specs (or xtest in Test::Unit), but alas I'm a forgetful person and have been known to check in commented out specs. I think the suite should fail, or at least give a warning in this case. I also don't use Textmate, so it could be my problem... I don't believe that I've ever seen it used to allow tests to be ignored in advance of implementation. I've only ever seen it used to ignore existing tests that had been passing and were now failing. Worse, I've seen this cause yellow to become the new green (i.e. an acceptable state for commits and sometimes even releases). Absolutely vile. This seems like a "process" or "people" issue rather than a tool issue. Policy could be set to not allow yellow builds in CI or for releases. The tool can be abused even with a red/green build. For example, people can comment out specs or x out tests to get the green build. Of course, if you insist on violating one of the most basic principles of > BDD, you can write up your spec code and comment it out. The commented code > would be in a logical place, but the tool would not be condoning the > practice. Commenting out the spec seems akin to sweeping the issue under the rug. If it shows up as a warning, at least it can be tracked. ---------- Forwarded message ---------- From: noreply at rubyforge.org Date: Oct 29, 2006 11:57 PM Subject: [ rspec-Feature Requests-6396 ] Disabled Specifications and a Yellow build To: noreply at rubyforge.org Feature Requests item #6396, was opened at 2006-10-29 23:51 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6396&group_id=797 Category: runner module Group: None Status: Open Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: Disabled Specifications and a Yellow build Initial Comment: Add a method that denotes a specification is disabled and causes a yellow build. For example: disable_specify "should support disabled specifications" do end This will be helpful in writing a spec before the feature is implemented. ---------------------------------------------------------------------- >Comment By: Brian Takita (btakita) Date: 2006-10-29 23:57 Message: I submitted this. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6396&group_id=797 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061030/ef9e0135/attachment.html From aslak.hellesoy at gmail.com Mon Oct 30 20:42:20 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Tue, 31 Oct 2006 03:42:20 +0200 Subject: [rspec-devel] Spec a spec generator In-Reply-To: <246e442a0610301702l64446cf2p6f99e59836e7de63@mail.gmail.com> References: <246e442a0610300006n5babb1d1wd22d538fa056d4a5@mail.gmail.com> <57c63afe0610300123l4d068972h6adc30b9171b29df@mail.gmail.com> <8d961d900610300543o57e87bd3r4828f1347f5fdc82@mail.gmail.com> <246e442a0610301356x3e965c0cxe36384b31f757b20@mail.gmail.com> <8d961d900610301513m42cb1984pb843b919432a2dc4@mail.gmail.com> <246e442a0610301702l64446cf2p6f99e59836e7de63@mail.gmail.com> Message-ID: <8d961d900610301742h195dafc8u264db30947c66eab@mail.gmail.com> On 10/31/06, Jeff Dean wrote: > "ruby script/generate rspec" did the trick for getting the specs to start > running, but now I'm getting an error and after looking through each of the > files, I still can't figure out what the problem is. > > D:/rails/rspec/vendor/rspec_on_rails/vendor/plugins/rspec/lib/extensions/test/rails.rb > line 1 is: > > require 'test/rails'This seems to be trying to require itself and I don't > know if that is correct or if it should be pointing to somewhere else. > It's not trying to include itself, it's trying to include a file from zentest (on which rspec on rails has a dependency) gem install ZenTest should get you further > I'll keep looking through this, and any help would be appreciated. Here's > the error message: > > C:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > `gem_original_require': no such file to load -- test/rails > (MissingSourceFile) > from > C:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > `require' > from > D:/rails/rspec/vendor/rspec_on_rails/config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:400:in > `require' > from > D:/rails/rspec/vendor/rspec_on_rails/vendor/plugins/rspec/lib/extensions/test/rails.rb:1 > from > C:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > `require' > from > D:/rails/rspec/vendor/rspec_on_rails/config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:400:in > `require' > from > D:/rails/rspec/vendor/rspec_on_rails/config/../vendor/plugins/rspec/lib/rspec_on_rails.rb:16 > from > C:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > `require' > from > D:/rails/rspec/vendor/rspec_on_rails/config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:400:in > `require' > from > ./vendor/plugins/rspec/spec/../../../../spec/spec_helper.rb:3 > from > C:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > `require' > from ./vendor/plugins/rspec/spec/spec_helper.rb:1 > from > C:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > `require' > from > ./vendor/plugins/rspec/spec/context_factory_spec.rb:1 > from > C:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > `require' > from D:/rails/rspec/bin/spec:14 > from D:/rails/rspec/bin/spec:8 > > Jeff > > > On 10/30/06, aslak hellesoy < aslak.hellesoy at gmail.com> wrote: > > On 10/30/06, Jeff Dean < jeff at jefdean.com> wrote: > > > I just tried to run rake spec:plugins from trunk and got the following > error > > > message. I have the 0.6.4 gem installed. > > > > > > D:\rails\rspec\vendor\rspec_on_rails>rake spec:plugins > > > (in D:/rails/rspec/vendor/rspec_on_rails) > > > c:/ruby/bin/ruby -I"D:/rails/rspec/lib" "D:/rails/rspec/bin/spec" > > > "vendor/plugins/rspec/spec/context_factory_spec.rb" > > > > "vendor/plugins/rspec/spec/controller_isolation_spec.rb" > > > "vendor/plugins/rspec/spe > > > c/opts_merger_spec.rb" > > > > "vendor/plugins/rspec/spec/expectations/should_be_spec.rb" > > > > "vendor/plugins/rspec/spec/expectations/should_have_rjs_spec.rb" > > > "vendor/plugins/rspec/spec/expectations/should_have_t > > > ag_spec.rb" > > > > "vendor/plugins/rspec/spec/expectations/should_not_have_rjs_spec.rb" > > > > "vendor/plugins/rspec/spec/expectations/should_not_have_tag_spec.rb" > > > "vendor/plugins/rspec/spec/expectations/should_not > > > _render_rjs_spec.rb" > > > > "vendor/plugins/rspec/spec/expectations/should_render_rjs_spec.rb" > > > > "vendor/plugins/rspec/spec/expectations/should_render_spec.rb" > > > "vendor/plugins/rspec/spec/generators/rspec_resou > > > rce_scaffold_spec.rb" > > > > c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > > `gem_original_require': no such file to load -- controller_mixin > > > (MissingSourceFile) > > > from > > > > c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > > `require' > > > from > > > > D:/rails/rspec/vendor/rspec_on_rails/config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:400:in > > > `require' > > > from > > > > ./vendor/plugins/rspec/spec/../../../../spec/spec_helper.rb:3 > > > from > > > > c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > > `require' > > > from > ./vendor/plugins/rspec/spec/spec_helper.rb:1 > > > from > > > > c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > > `require' > > > from > > > ./vendor/plugins/rspec/spec/context_factory_spec.rb:1 > > > from > > > > c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > > `require' > > > from D:/rails/rspec/bin/spec:14 > > > from D:/rails/rspec/bin/spec:8 > > > rake aborted! > > > Command failed with status (1): [c:/ruby/bin/ruby -I"D:/rails/rspec/lib" > > > "D...] > > > > > > Do I have to uninstall the gem to make this work? > > > > > > > No, but you have to re-bootstrap the rails project by first running: > > > > ruby script/generate rspec > > > > Aslak > > > > > > > > > > > > > > On 10/30/06, aslak hellesoy wrote: > > > > On 10/30/06, David Chelimsky < dchelimsky at gmail.com> wrote: > > > > > On 10/30/06, Jeff Dean wrote: > > > > > > I just created an rspec_scaffold_resource generator and I've got a > few > > > > > > questions about what the next steps are. > > > > > > > > > > > > First, this is a total noob question, but how do I run the specs > from > > > > > > > rspec/vendor/rspec_on_rails/vendor/plugins/rspec/spec > > > from > > > > > > the command line? I haven't written specs for the generator yet > > > because I > > > > > > don't know how to run them. > > > > > > > > > > Assuming you've checked out the source and have all the > dependencies, > > > > > stand in vendor/rspec_on_rails and say "rake spec:plugins" or > > > > > "../../bin/spec vendor/plugins/rspec/spec". > > > > > > > > > > > > > > > > > Second, rspec_scaffold_resource depends on edge rails. Is it safe > to > > > assume > > > > > > that if you are running rspec_scaffold_resource that you are > already > > > running > > > > > > edge, or should I try to check for it somehow? On a related note > - > > > since > > > > > > you can't run it without edge, you need to freeze edge or add an > > > > > > svn:externals property to even try it out. > > > > > > > > > > > > > For now, just assume edge rails is available. > > > > > > > > > This is something I hadn't considered. We don't have any official > > > > > support policy, and given that nobody working on this does so full > > > > > time, any such policy would have to take that into account. The most > > > > > reasonable policy I can think of is that we should do our best to > > > > > ensuring that any rspec release works w/ the latest rails stable > > > > > release at the time. This would, obviously, not pertain to edge > rails. > > > > > Maybe some day enough people will use rspec on rails and the rails > > > > > core team will have the good sense to incorporate this functionality > > > > > right into rails (you can say-ay-ay I'm a dreamer.....). > > > > > > > > > > In the mean time, this does present an interesting dilemma. What if > we > > > > > were to set up the build so that running "rake pre_commit" will run > > > > > everything but these edge-rails-specific specs against the latest > > > > > stable rails and fail the build if anything fails, but then run > > > > > everything including the edge-rails-specific specs and only report > if > > > > > anything fails, but still pass the build? That would keep us > > > > > progressing without turning edge rails into a bottleneck, but would > > > > > also keep edge rails constantly on the radar. > > > > > > > > > > If that makes sense to everyone, I'm sure we can figure out a way to > do > > > it. > > > > > > > > > > > > > A script that specifies an array of svn tags and trunk. E.g. > > > > ['tags/1.1.6', 'trunk'] > > > > We'd loop through this array and run rake spec for all of them. > > > > > > > > Each spec could have its body in an if block a la: > > > > > > > > if(RAILS_VERSION > 1.1.6) > > > > specify "something that should only work on edge" do > > > > ... > > > > end > > > > end > > > > > > > > > > Third, I'm not too experienced with patching, but I assume that > the > > > > > > TortosieSVN's "create patch" and specifying all of the > new/modified > > > files > > > > > > should do the trick. Is there anything else I should know? Any > > > > > > incompatibilities I should watch out for? > > > > > > > > > > I've not used TortoiseSVN to create a patch, so someone else will > have > > > > > to comment on this. > > > > > > > > > > > > > create patch should work. Make sure to attach entirely new files too. > > > > At rubyforge, add a comment to your patches, so we can distinguish > > > > older from newer patches. > > > > > > > > > > And last - I know that the directory structure will change soon, > and > > > since > > > > > > the generator creates files I imagine I'd want to test that these > > > files are > > > > > > correctly created. I'd like to write a comprehensive spec, but > I'd > > > prefer > > > > > > not to write it twice (if the directory changes will affect the > sample > > > rails > > > > > > app). Any thoughts on how to proceed here? > > > > > > > > > > What that is going to look like is totally unknown right now. There > > > > > are wide reaching implications in our build - for example, almost > all > > > > > of the examples on the website, including those for rspec on rails, > > > > > get run with "rake pre_commit". This guarantees that the examples > > > > > actually work, which is an important feature that I'd not be very > > > > > willing to give up. So the existing example app will need to live > > > > > somewhere (so we can use it for the documentation), though it is not > > > > > necessary for it to live in the same directory structure as the > plugin > > > > > code. > > > > > > > > > > Also, some of the specs in > > > > > vendor/rspec_on_rails/vendor/plugins/rspec/spec > (which > > > specify the > > > > > plugin) use controllers and views that are assumed to be where they > > > > > would normally be in a rails app. In order to move them beneath the > > > > > plugin dirs, we'd have to override all of the underlying rails > mapping > > > > > mojo. The more I think of that, the less sense it makes to me - BUT, > > > > > not making that move means that you can't run those specs without > > > > > having the specified controllers, helpers, views, etc in their > natural > > > > > homes. Kinda sucks. > > > > > > > > > > All of that said, I'm not sure where this is leading, so the best > > > > > advice I can offer is to work w/in the existing directory structure > > > > > (in trunk) and hope for the best. There's no guarantee any of this > > > > > will move anywhere, so why let that impede your work now? > > > > > > > > > > > Thanks in advance for your time, > > > > > > > > > > And for yours! > > > > > > > > > > Cheers, > > > > > David > > > > > > > > > > > > > > > > > Jeff > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > rspec-devel mailing list > > > > > > rspec-devel at rubyforge.org > > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > rspec-devel mailing list > > > > > rspec-devel at rubyforge.org > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > _______________________________________________ > > > > rspec-devel mailing list > > > > rspec-devel at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > _______________________________________________ > > > rspec-devel mailing list > > > rspec-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > From aslak.hellesoy at gmail.com Mon Oct 30 20:53:59 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Tue, 31 Oct 2006 03:53:59 +0200 Subject: [rspec-devel] Wider context for RSpec: GUI testing? In-Reply-To: References: Message-ID: <8d961d900610301753k6843d049vfdbddafdb74fc1fa@mail.gmail.com> On 10/31/06, Ian Dees wrote: > Hi, all. > > I love RSpec's ease of expressing an author's desired behavior for > software. That got me thinking about a little wider context (pun > unintended) for the meaning of "behavior." It seems like the sweet > spot for RSpec is unit testing of Ruby classes (perhaps including > Rails models and controllers). But here in the office, we're also > beginning to find it useful for specifying GUI behavior. > > Of course, now that we're outside the original BDD roots of RSpec, > there are some philosophical questions, many of which boil down to, > "What's the best way of selectively enabling/disabling certain tests?" > where "best" means, "most RSpec-like?" > > Let me give you two examples: > > 1) For localized applications, some tests might be written cleverly > enough to work in _any_ language build of the software, while other > tests might be language-specific (maybe they depend on a GUI element > having a certain caption, and its identity can't be deduced by any > other method). > > 2) Some GUI tests might require at least partial manual intervention; > it would be nice to skip these tests when running an overnight, > batch-mode test. > > I can imagine a few different approaches in RSpec: > > 1) I could separate the tests into different files by my selection > criteria: put the English-only tests in their own file, or put the > partially manual tests in their own file. The main downside here is > that sometimes the most logical way to group tests isn't necessarily > by language or degree of automation. > > 2) I could extend RSpec (thanks, Ruby!) to allow me to specify > optional criteria for a context, something like: > > context "The Borfin", :interactive => :true do > specify "should not go shlump after Mr. Bix un-shlumps it" do > # drive the GUI and maybe prompt the tester to do physical stuff > end > end > > 3) Like #2 above, but for individual specifications instead of contexts. > > I lean toward #2, but I wanted to bounce my question off the RSpec > devels, since the list archives reveal that you have been thinking a > great deal about the semantics of tests. > > What I _don't_ want to do is pollute RSpec with a bunch of GUI testing > cruft. It would be nice to use RSpec in this new domain without > compromising its simplicity in its primary domain. Again, though, > that's where Ruby's open classes sure come in handy. > > Thanks in advance for your thoughts. > A simple solution would be: context ... do if(ENV['ENGLISH_SPECS']) specify "something that should only work in English mode" do end end end Or better: context ... do if english? specify "something that should only work in English mode" do end end end -And define the english method in a spec_helper.rb (that you include at the top of your spec) and contains the following: class Spec::ContextEvalModule def english? !ENV['ENGLISH_SPECS'].nil? end end The turning it on is just a matter of defining a shell env var Aslak > Sincerely, > > Ian Dees > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dchelimsky at gmail.com Mon Oct 30 21:58:47 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 30 Oct 2006 21:58:47 -0500 Subject: [rspec-devel] Wider context for RSpec: GUI testing? In-Reply-To: References: Message-ID: <57c63afe0610301858k794df6eel928840d9a2027933@mail.gmail.com> On 10/30/06, Ian Dees wrote: > Hi, all. > > I love RSpec's ease of expressing an author's desired behavior for > software. That got me thinking about a little wider context (pun > unintended) for the meaning of "behavior." It seems like the sweet > spot for RSpec is unit testing of Ruby classes (perhaps including > Rails models and controllers). That may be its sweet spot, but BDD can be top to bottom proposition, and we'd like to support that in the long run. >But here in the office, we're also > beginning to find it useful for specifying GUI behavior. Sweet! > Of course, now that we're outside the original BDD roots of RSpec, We really need to talk about this! > there are some philosophical questions, many of which boil down to, > "What's the best way of selectively enabling/disabling certain tests?" > where "best" means, "most RSpec-like?" Now you're talking! > > Let me give you two examples: > > 1) For localized applications, some tests might be written cleverly > enough to work in _any_ language build of the software, while other > tests might be language-specific (maybe they depend on a GUI element > having a certain caption, and its identity can't be deduced by any > other method). > > 2) Some GUI tests might require at least partial manual intervention; > it would be nice to skip these tests when running an overnight, > batch-mode test. > > I can imagine a few different approaches in RSpec: > > 1) I could separate the tests into different files by my selection > criteria: put the English-only tests in their own file, or put the > partially manual tests in their own file. The main downside here is > that sometimes the most logical way to group tests isn't necessarily > by language or degree of automation. > > 2) I could extend RSpec (thanks, Ruby!) to allow me to specify > optional criteria for a context, something like: > > context "The Borfin", :interactive => :true do > specify "should not go shlump after Mr. Bix un-shlumps it" do > # drive the GUI and maybe prompt the tester to do physical stuff > end > end > > 3) Like #2 above, but for individual specifications instead of contexts. > > I lean toward #2, but I wanted to bounce my question off the RSpec > devels, since the list archives reveal that you have been thinking a > great deal about the semantics of tests. > > What I _don't_ want to do is pollute RSpec with a bunch of GUI testing > cruft. It would be nice to use RSpec in this new domain without > compromising its simplicity in its primary domain. Again, though, > that's where Ruby's open classes sure come in handy. How about this? We add a spec command option that allows you to set a series of one or more key/value pairs: -i or --include spec -i":lingua => 'portugu?s', :lingua => 'fran?ais'" That would run only specs or contexts set up like so: context "blah in portuguese", :lingua => 'portugu?s' do ... end context "..." do specify "blah in french", :lingua => 'fran?ais' do ... end end This could be used for all sorts of suite organization, and can be automated through rake tasks. Sound like a good approach? David > > Thanks in advance for your thoughts. > > Sincerely, > > Ian Dees > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dchelimsky at gmail.com Mon Oct 30 22:04:23 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 30 Oct 2006 22:04:23 -0500 Subject: [rspec-devel] Spec a spec generator In-Reply-To: <8d961d900610301742h195dafc8u264db30947c66eab@mail.gmail.com> References: <246e442a0610300006n5babb1d1wd22d538fa056d4a5@mail.gmail.com> <57c63afe0610300123l4d068972h6adc30b9171b29df@mail.gmail.com> <8d961d900610300543o57e87bd3r4828f1347f5fdc82@mail.gmail.com> <246e442a0610301356x3e965c0cxe36384b31f757b20@mail.gmail.com> <8d961d900610301513m42cb1984pb843b919432a2dc4@mail.gmail.com> <246e442a0610301702l64446cf2p6f99e59836e7de63@mail.gmail.com> <8d961d900610301742h195dafc8u264db30947c66eab@mail.gmail.com> Message-ID: <57c63afe0610301904q61a09377q55af10b7a90e9f8a@mail.gmail.com> On 10/30/06, aslak hellesoy wrote: > On 10/31/06, Jeff Dean wrote: > > "ruby script/generate rspec" did the trick for getting the specs to start > > running, but now I'm getting an error and after looking through each of the > > files, I still can't figure out what the problem is. > > > > D:/rails/rspec/vendor/rspec_on_rails/vendor/plugins/rspec/lib/extensions/test/rails.rb > > line 1 is: > > > > require 'test/rails'This seems to be trying to require itself and I don't > > know if that is correct or if it should be pointing to somewhere else. > > > > It's not trying to include itself, it's trying to include a file from > zentest (on which rspec on rails has a dependency) > > gem install ZenTest > > should get you further Ah yes. The new plugin extends (and therefore depends on) ZenTest. This is something that will be well documented prior to the release. > > > I'll keep looking through this, and any help would be appreciated. Here's > > the error message: > > > > C:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > `gem_original_require': no such file to load -- test/rails > > (MissingSourceFile) > > from > > C:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > `require' > > from > > D:/rails/rspec/vendor/rspec_on_rails/config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:400:in > > `require' > > from > > D:/rails/rspec/vendor/rspec_on_rails/vendor/plugins/rspec/lib/extensions/test/rails.rb:1 > > from > > C:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > `require' > > from > > D:/rails/rspec/vendor/rspec_on_rails/config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:400:in > > `require' > > from > > D:/rails/rspec/vendor/rspec_on_rails/config/../vendor/plugins/rspec/lib/rspec_on_rails.rb:16 > > from > > C:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > `require' > > from > > D:/rails/rspec/vendor/rspec_on_rails/config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:400:in > > `require' > > from > > ./vendor/plugins/rspec/spec/../../../../spec/spec_helper.rb:3 > > from > > C:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > `require' > > from ./vendor/plugins/rspec/spec/spec_helper.rb:1 > > from > > C:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > `require' > > from > > ./vendor/plugins/rspec/spec/context_factory_spec.rb:1 > > from > > C:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > `require' > > from D:/rails/rspec/bin/spec:14 > > from D:/rails/rspec/bin/spec:8 > > > > Jeff > > > > > > On 10/30/06, aslak hellesoy < aslak.hellesoy at gmail.com> wrote: > > > On 10/30/06, Jeff Dean < jeff at jefdean.com> wrote: > > > > I just tried to run rake spec:plugins from trunk and got the following > > error > > > > message. I have the 0.6.4 gem installed. > > > > > > > > D:\rails\rspec\vendor\rspec_on_rails>rake spec:plugins > > > > (in D:/rails/rspec/vendor/rspec_on_rails) > > > > c:/ruby/bin/ruby -I"D:/rails/rspec/lib" "D:/rails/rspec/bin/spec" > > > > "vendor/plugins/rspec/spec/context_factory_spec.rb" > > > > > > "vendor/plugins/rspec/spec/controller_isolation_spec.rb" > > > > "vendor/plugins/rspec/spe > > > > c/opts_merger_spec.rb" > > > > > > "vendor/plugins/rspec/spec/expectations/should_be_spec.rb" > > > > > > "vendor/plugins/rspec/spec/expectations/should_have_rjs_spec.rb" > > > > "vendor/plugins/rspec/spec/expectations/should_have_t > > > > ag_spec.rb" > > > > > > "vendor/plugins/rspec/spec/expectations/should_not_have_rjs_spec.rb" > > > > > > "vendor/plugins/rspec/spec/expectations/should_not_have_tag_spec.rb" > > > > "vendor/plugins/rspec/spec/expectations/should_not > > > > _render_rjs_spec.rb" > > > > > > "vendor/plugins/rspec/spec/expectations/should_render_rjs_spec.rb" > > > > > > "vendor/plugins/rspec/spec/expectations/should_render_spec.rb" > > > > "vendor/plugins/rspec/spec/generators/rspec_resou > > > > rce_scaffold_spec.rb" > > > > > > c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > > > `gem_original_require': no such file to load -- controller_mixin > > > > (MissingSourceFile) > > > > from > > > > > > c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > > > `require' > > > > from > > > > > > D:/rails/rspec/vendor/rspec_on_rails/config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:400:in > > > > `require' > > > > from > > > > > > ./vendor/plugins/rspec/spec/../../../../spec/spec_helper.rb:3 > > > > from > > > > > > c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > > > `require' > > > > from > > ./vendor/plugins/rspec/spec/spec_helper.rb:1 > > > > from > > > > > > c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > > > `require' > > > > from > > > > ./vendor/plugins/rspec/spec/context_factory_spec.rb:1 > > > > from > > > > > > c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > > > `require' > > > > from D:/rails/rspec/bin/spec:14 > > > > from D:/rails/rspec/bin/spec:8 > > > > rake aborted! > > > > Command failed with status (1): [c:/ruby/bin/ruby -I"D:/rails/rspec/lib" > > > > "D...] > > > > > > > > Do I have to uninstall the gem to make this work? > > > > > > > > > > No, but you have to re-bootstrap the rails project by first running: > > > > > > ruby script/generate rspec > > > > > > Aslak > > > > > > > > > > > > > > > > > > > On 10/30/06, aslak hellesoy wrote: > > > > > On 10/30/06, David Chelimsky < dchelimsky at gmail.com> wrote: > > > > > > On 10/30/06, Jeff Dean wrote: > > > > > > > I just created an rspec_scaffold_resource generator and I've got a > > few > > > > > > > questions about what the next steps are. > > > > > > > > > > > > > > First, this is a total noob question, but how do I run the specs > > from > > > > > > > > > rspec/vendor/rspec_on_rails/vendor/plugins/rspec/spec > > > > from > > > > > > > the command line? I haven't written specs for the generator yet > > > > because I > > > > > > > don't know how to run them. > > > > > > > > > > > > Assuming you've checked out the source and have all the > > dependencies, > > > > > > stand in vendor/rspec_on_rails and say "rake spec:plugins" or > > > > > > "../../bin/spec vendor/plugins/rspec/spec". > > > > > > > > > > > > > > > > > > > > Second, rspec_scaffold_resource depends on edge rails. Is it safe > > to > > > > assume > > > > > > > that if you are running rspec_scaffold_resource that you are > > already > > > > running > > > > > > > edge, or should I try to check for it somehow? On a related note > > - > > > > since > > > > > > > you can't run it without edge, you need to freeze edge or add an > > > > > > > svn:externals property to even try it out. > > > > > > > > > > > > > > > > For now, just assume edge rails is available. > > > > > > > > > > > This is something I hadn't considered. We don't have any official > > > > > > support policy, and given that nobody working on this does so full > > > > > > time, any such policy would have to take that into account. The most > > > > > > reasonable policy I can think of is that we should do our best to > > > > > > ensuring that any rspec release works w/ the latest rails stable > > > > > > release at the time. This would, obviously, not pertain to edge > > rails. > > > > > > Maybe some day enough people will use rspec on rails and the rails > > > > > > core team will have the good sense to incorporate this functionality > > > > > > right into rails (you can say-ay-ay I'm a dreamer.....). > > > > > > > > > > > > In the mean time, this does present an interesting dilemma. What if > > we > > > > > > were to set up the build so that running "rake pre_commit" will run > > > > > > everything but these edge-rails-specific specs against the latest > > > > > > stable rails and fail the build if anything fails, but then run > > > > > > everything including the edge-rails-specific specs and only report > > if > > > > > > anything fails, but still pass the build? That would keep us > > > > > > progressing without turning edge rails into a bottleneck, but would > > > > > > also keep edge rails constantly on the radar. > > > > > > > > > > > > If that makes sense to everyone, I'm sure we can figure out a way to > > do > > > > it. > > > > > > > > > > > > > > > > A script that specifies an array of svn tags and trunk. E.g. > > > > > ['tags/1.1.6', 'trunk'] > > > > > We'd loop through this array and run rake spec for all of them. > > > > > > > > > > Each spec could have its body in an if block a la: > > > > > > > > > > if(RAILS_VERSION > 1.1.6) > > > > > specify "something that should only work on edge" do > > > > > ... > > > > > end > > > > > end > > > > > > > > > > > > Third, I'm not too experienced with patching, but I assume that > > the > > > > > > > TortosieSVN's "create patch" and specifying all of the > > new/modified > > > > files > > > > > > > should do the trick. Is there anything else I should know? Any > > > > > > > incompatibilities I should watch out for? > > > > > > > > > > > > I've not used TortoiseSVN to create a patch, so someone else will > > have > > > > > > to comment on this. > > > > > > > > > > > > > > > > create patch should work. Make sure to attach entirely new files too. > > > > > At rubyforge, add a comment to your patches, so we can distinguish > > > > > older from newer patches. > > > > > > > > > > > > And last - I know that the directory structure will change soon, > > and > > > > since > > > > > > > the generator creates files I imagine I'd want to test that these > > > > files are > > > > > > > correctly created. I'd like to write a comprehensive spec, but > > I'd > > > > prefer > > > > > > > not to write it twice (if the directory changes will affect the > > sample > > > > rails > > > > > > > app). Any thoughts on how to proceed here? > > > > > > > > > > > > What that is going to look like is totally unknown right now. There > > > > > > are wide reaching implications in our build - for example, almost > > all > > > > > > of the examples on the website, including those for rspec on rails, > > > > > > get run with "rake pre_commit". This guarantees that the examples > > > > > > actually work, which is an important feature that I'd not be very > > > > > > willing to give up. So the existing example app will need to live > > > > > > somewhere (so we can use it for the documentation), though it is not > > > > > > necessary for it to live in the same directory structure as the > > plugin > > > > > > code. > > > > > > > > > > > > Also, some of the specs in > > > > > > vendor/rspec_on_rails/vendor/plugins/rspec/spec > > (which > > > > specify the > > > > > > plugin) use controllers and views that are assumed to be where they > > > > > > would normally be in a rails app. In order to move them beneath the > > > > > > plugin dirs, we'd have to override all of the underlying rails > > mapping > > > > > > mojo. The more I think of that, the less sense it makes to me - BUT, > > > > > > not making that move means that you can't run those specs without > > > > > > having the specified controllers, helpers, views, etc in their > > natural > > > > > > homes. Kinda sucks. > > > > > > > > > > > > All of that said, I'm not sure where this is leading, so the best > > > > > > advice I can offer is to work w/in the existing directory structure > > > > > > (in trunk) and hope for the best. There's no guarantee any of this > > > > > > will move anywhere, so why let that impede your work now? > > > > > > > > > > > > > Thanks in advance for your time, > > > > > > > > > > > > And for yours! > > > > > > > > > > > > Cheers, > > > > > > David > > > > > > > > > > > > > > > > > > > > Jeff > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > rspec-devel mailing list > > > > > > > rspec-devel at rubyforge.org > > > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > rspec-devel mailing list > > > > > > rspec-devel at rubyforge.org > > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > _______________________________________________ > > > > > rspec-devel mailing list > > > > > rspec-devel at rubyforge.org > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > > > > > _______________________________________________ > > > > rspec-devel mailing list > > > > rspec-devel at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > _______________________________________________ > > > rspec-devel mailing list > > > rspec-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dchelimsky at gmail.com Mon Oct 30 22:06:13 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 30 Oct 2006 22:06:13 -0500 Subject: [rspec-devel] Rails questions to this list In-Reply-To: <8d961d900610281544v7710a135ib965b828607e4f85@mail.gmail.com> References: <8d961d900610281544v7710a135ib965b828607e4f85@mail.gmail.com> Message-ID: <57c63afe0610301906u49af3608g65a78bcaa78a9333@mail.gmail.com> On 10/28/06, aslak hellesoy wrote: > Can we put up a page on the web page that says something like: > > If you think you have found a bug in RSpec on Rails then: > 1) Code a similar test in Test::Unit first to make sure it's an issue > that only happens in RSpec on Rails (if possible) > 2) Submit complete code that allows us to reproduce it > > Then we can point people to that page if we think we're dealing with > non-rspec issues (dumb user error or inherent rails issues) I plan to add a "Contribute" page that would include this and other stuff about submitting patches and RFEs (to the tracker rather than the list). > > Aslak > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From aslak.hellesoy at gmail.com Tue Oct 31 03:32:27 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Tue, 31 Oct 2006 09:32:27 +0100 Subject: [rspec-devel] Wider context for RSpec: GUI testing? In-Reply-To: <57c63afe0610301858k794df6eel928840d9a2027933@mail.gmail.com> References: <57c63afe0610301858k794df6eel928840d9a2027933@mail.gmail.com> Message-ID: <8d961d900610310032s5ece19d5x8f0651c9f3919193@mail.gmail.com> On 10/31/06, David Chelimsky wrote: > On 10/30/06, Ian Dees wrote: > > Hi, all. > > > > I love RSpec's ease of expressing an author's desired behavior for > > software. That got me thinking about a little wider context (pun > > unintended) for the meaning of "behavior." It seems like the sweet > > spot for RSpec is unit testing of Ruby classes (perhaps including > > Rails models and controllers). > > That may be its sweet spot, but BDD can be top to bottom proposition, > and we'd like to support that in the long run. > > >But here in the office, we're also > > beginning to find it useful for specifying GUI behavior. > > Sweet! > > > Of course, now that we're outside the original BDD roots of RSpec, > > We really need to talk about this! > > > there are some philosophical questions, many of which boil down to, > > "What's the best way of selectively enabling/disabling certain tests?" > > where "best" means, "most RSpec-like?" > > Now you're talking! > > > > > Let me give you two examples: > > > > 1) For localized applications, some tests might be written cleverly > > enough to work in _any_ language build of the software, while other > > tests might be language-specific (maybe they depend on a GUI element > > having a certain caption, and its identity can't be deduced by any > > other method). > > > > 2) Some GUI tests might require at least partial manual intervention; > > it would be nice to skip these tests when running an overnight, > > batch-mode test. > > > > I can imagine a few different approaches in RSpec: > > > > 1) I could separate the tests into different files by my selection > > criteria: put the English-only tests in their own file, or put the > > partially manual tests in their own file. The main downside here is > > that sometimes the most logical way to group tests isn't necessarily > > by language or degree of automation. > > > > 2) I could extend RSpec (thanks, Ruby!) to allow me to specify > > optional criteria for a context, something like: > > > > context "The Borfin", :interactive => :true do > > specify "should not go shlump after Mr. Bix un-shlumps it" do > > # drive the GUI and maybe prompt the tester to do physical stuff > > end > > end > > > > 3) Like #2 above, but for individual specifications instead of contexts. > > > > I lean toward #2, but I wanted to bounce my question off the RSpec > > devels, since the list archives reveal that you have been thinking a > > great deal about the semantics of tests. > > > > What I _don't_ want to do is pollute RSpec with a bunch of GUI testing > > cruft. It would be nice to use RSpec in this new domain without > > compromising its simplicity in its primary domain. Again, though, > > that's where Ruby's open classes sure come in handy. > > How about this? We add a spec command option that allows you to set a > series of one or more key/value pairs: > > -i or --include > > spec -i":lingua => 'portugu?s', :lingua => 'fran?ais'" > > That would run only specs or contexts set up like so: > > context "blah in portuguese", :lingua => 'portugu?s' do > ... > end > > context "..." do > specify "blah in french", :lingua => 'fran?ais' do > ... > end > end > > This could be used for all sorts of suite organization, and can be > automated through rake tasks. > > Sound like a good approach? > Interesting, but it sounds somewhat redundant to the -s option. > David > > > > > > Thanks in advance for your thoughts. > > > > Sincerely, > > > > Ian Dees > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From aslak.hellesoy at gmail.com Tue Oct 31 04:33:46 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Tue, 31 Oct 2006 10:33:46 +0100 Subject: [rspec-devel] Spec a spec generator In-Reply-To: <57c63afe0610301904q61a09377q55af10b7a90e9f8a@mail.gmail.com> References: <246e442a0610300006n5babb1d1wd22d538fa056d4a5@mail.gmail.com> <57c63afe0610300123l4d068972h6adc30b9171b29df@mail.gmail.com> <8d961d900610300543o57e87bd3r4828f1347f5fdc82@mail.gmail.com> <246e442a0610301356x3e965c0cxe36384b31f757b20@mail.gmail.com> <8d961d900610301513m42cb1984pb843b919432a2dc4@mail.gmail.com> <246e442a0610301702l64446cf2p6f99e59836e7de63@mail.gmail.com> <8d961d900610301742h195dafc8u264db30947c66eab@mail.gmail.com> <57c63afe0610301904q61a09377q55af10b7a90e9f8a@mail.gmail.com> Message-ID: <8d961d900610310133k1b6ebe35haf548fb14ce6142a@mail.gmail.com> On 10/31/06, David Chelimsky wrote: > On 10/30/06, aslak hellesoy wrote: > > On 10/31/06, Jeff Dean wrote: > > > "ruby script/generate rspec" did the trick for getting the specs to start > > > running, but now I'm getting an error and after looking through each of the > > > files, I still can't figure out what the problem is. > > > > > > D:/rails/rspec/vendor/rspec_on_rails/vendor/plugins/rspec/lib/extensions/test/rails.rb > > > line 1 is: > > > > > > require 'test/rails'This seems to be trying to require itself and I don't > > > know if that is correct or if it should be pointing to somewhere else. > > > > > > > It's not trying to include itself, it's trying to include a file from > > zentest (on which rspec on rails has a dependency) > > > > gem install ZenTest > > > > should get you further > > Ah yes. The new plugin extends (and therefore depends on) ZenTest. > This is something that will be well documented prior to the release. > I've surrounded the require code ina begin/rescue that will tell you that explicitly in case people don't RTFM ;-) > > > > > I'll keep looking through this, and any help would be appreciated. Here's > > > the error message: > > > > > > C:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > > `gem_original_require': no such file to load -- test/rails > > > (MissingSourceFile) > > > from > > > C:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > > `require' > > > from > > > D:/rails/rspec/vendor/rspec_on_rails/config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:400:in > > > `require' > > > from > > > D:/rails/rspec/vendor/rspec_on_rails/vendor/plugins/rspec/lib/extensions/test/rails.rb:1 > > > from > > > C:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > > `require' > > > from > > > D:/rails/rspec/vendor/rspec_on_rails/config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:400:in > > > `require' > > > from > > > D:/rails/rspec/vendor/rspec_on_rails/config/../vendor/plugins/rspec/lib/rspec_on_rails.rb:16 > > > from > > > C:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > > `require' > > > from > > > D:/rails/rspec/vendor/rspec_on_rails/config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:400:in > > > `require' > > > from > > > ./vendor/plugins/rspec/spec/../../../../spec/spec_helper.rb:3 > > > from > > > C:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > > `require' > > > from ./vendor/plugins/rspec/spec/spec_helper.rb:1 > > > from > > > C:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > > `require' > > > from > > > ./vendor/plugins/rspec/spec/context_factory_spec.rb:1 > > > from > > > C:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > > `require' > > > from D:/rails/rspec/bin/spec:14 > > > from D:/rails/rspec/bin/spec:8 > > > > > > Jeff > > > > > > > > > On 10/30/06, aslak hellesoy < aslak.hellesoy at gmail.com> wrote: > > > > On 10/30/06, Jeff Dean < jeff at jefdean.com> wrote: > > > > > I just tried to run rake spec:plugins from trunk and got the following > > > error > > > > > message. I have the 0.6.4 gem installed. > > > > > > > > > > D:\rails\rspec\vendor\rspec_on_rails>rake spec:plugins > > > > > (in D:/rails/rspec/vendor/rspec_on_rails) > > > > > c:/ruby/bin/ruby -I"D:/rails/rspec/lib" "D:/rails/rspec/bin/spec" > > > > > "vendor/plugins/rspec/spec/context_factory_spec.rb" > > > > > > > > "vendor/plugins/rspec/spec/controller_isolation_spec.rb" > > > > > "vendor/plugins/rspec/spe > > > > > c/opts_merger_spec.rb" > > > > > > > > "vendor/plugins/rspec/spec/expectations/should_be_spec.rb" > > > > > > > > "vendor/plugins/rspec/spec/expectations/should_have_rjs_spec.rb" > > > > > "vendor/plugins/rspec/spec/expectations/should_have_t > > > > > ag_spec.rb" > > > > > > > > "vendor/plugins/rspec/spec/expectations/should_not_have_rjs_spec.rb" > > > > > > > > "vendor/plugins/rspec/spec/expectations/should_not_have_tag_spec.rb" > > > > > "vendor/plugins/rspec/spec/expectations/should_not > > > > > _render_rjs_spec.rb" > > > > > > > > "vendor/plugins/rspec/spec/expectations/should_render_rjs_spec.rb" > > > > > > > > "vendor/plugins/rspec/spec/expectations/should_render_spec.rb" > > > > > "vendor/plugins/rspec/spec/generators/rspec_resou > > > > > rce_scaffold_spec.rb" > > > > > > > > c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > > > > `gem_original_require': no such file to load -- controller_mixin > > > > > (MissingSourceFile) > > > > > from > > > > > > > > c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > > > > `require' > > > > > from > > > > > > > > D:/rails/rspec/vendor/rspec_on_rails/config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:400:in > > > > > `require' > > > > > from > > > > > > > > ./vendor/plugins/rspec/spec/../../../../spec/spec_helper.rb:3 > > > > > from > > > > > > > > c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > > > > `require' > > > > > from > > > ./vendor/plugins/rspec/spec/spec_helper.rb:1 > > > > > from > > > > > > > > c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > > > > `require' > > > > > from > > > > > ./vendor/plugins/rspec/spec/context_factory_spec.rb:1 > > > > > from > > > > > > > > c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > > > > `require' > > > > > from D:/rails/rspec/bin/spec:14 > > > > > from D:/rails/rspec/bin/spec:8 > > > > > rake aborted! > > > > > Command failed with status (1): [c:/ruby/bin/ruby -I"D:/rails/rspec/lib" > > > > > "D...] > > > > > > > > > > Do I have to uninstall the gem to make this work? > > > > > > > > > > > > > No, but you have to re-bootstrap the rails project by first running: > > > > > > > > ruby script/generate rspec > > > > > > > > Aslak > > > > > > > > > > > > > > > > > > > > > > > > On 10/30/06, aslak hellesoy wrote: > > > > > > On 10/30/06, David Chelimsky < dchelimsky at gmail.com> wrote: > > > > > > > On 10/30/06, Jeff Dean wrote: > > > > > > > > I just created an rspec_scaffold_resource generator and I've got a > > > few > > > > > > > > questions about what the next steps are. > > > > > > > > > > > > > > > > First, this is a total noob question, but how do I run the specs > > > from > > > > > > > > > > > rspec/vendor/rspec_on_rails/vendor/plugins/rspec/spec > > > > > from > > > > > > > > the command line? I haven't written specs for the generator yet > > > > > because I > > > > > > > > don't know how to run them. > > > > > > > > > > > > > > Assuming you've checked out the source and have all the > > > dependencies, > > > > > > > stand in vendor/rspec_on_rails and say "rake spec:plugins" or > > > > > > > "../../bin/spec vendor/plugins/rspec/spec". > > > > > > > > > > > > > > > > > > > > > > > Second, rspec_scaffold_resource depends on edge rails. Is it safe > > > to > > > > > assume > > > > > > > > that if you are running rspec_scaffold_resource that you are > > > already > > > > > running > > > > > > > > edge, or should I try to check for it somehow? On a related note > > > - > > > > > since > > > > > > > > you can't run it without edge, you need to freeze edge or add an > > > > > > > > svn:externals property to even try it out. > > > > > > > > > > > > > > > > > > > For now, just assume edge rails is available. > > > > > > > > > > > > > This is something I hadn't considered. We don't have any official > > > > > > > support policy, and given that nobody working on this does so full > > > > > > > time, any such policy would have to take that into account. The most > > > > > > > reasonable policy I can think of is that we should do our best to > > > > > > > ensuring that any rspec release works w/ the latest rails stable > > > > > > > release at the time. This would, obviously, not pertain to edge > > > rails. > > > > > > > Maybe some day enough people will use rspec on rails and the rails > > > > > > > core team will have the good sense to incorporate this functionality > > > > > > > right into rails (you can say-ay-ay I'm a dreamer.....). > > > > > > > > > > > > > > In the mean time, this does present an interesting dilemma. What if > > > we > > > > > > > were to set up the build so that running "rake pre_commit" will run > > > > > > > everything but these edge-rails-specific specs against the latest > > > > > > > stable rails and fail the build if anything fails, but then run > > > > > > > everything including the edge-rails-specific specs and only report > > > if > > > > > > > anything fails, but still pass the build? That would keep us > > > > > > > progressing without turning edge rails into a bottleneck, but would > > > > > > > also keep edge rails constantly on the radar. > > > > > > > > > > > > > > If that makes sense to everyone, I'm sure we can figure out a way to > > > do > > > > > it. > > > > > > > > > > > > > > > > > > > A script that specifies an array of svn tags and trunk. E.g. > > > > > > ['tags/1.1.6', 'trunk'] > > > > > > We'd loop through this array and run rake spec for all of them. > > > > > > > > > > > > Each spec could have its body in an if block a la: > > > > > > > > > > > > if(RAILS_VERSION > 1.1.6) > > > > > > specify "something that should only work on edge" do > > > > > > ... > > > > > > end > > > > > > end > > > > > > > > > > > > > > Third, I'm not too experienced with patching, but I assume that > > > the > > > > > > > > TortosieSVN's "create patch" and specifying all of the > > > new/modified > > > > > files > > > > > > > > should do the trick. Is there anything else I should know? Any > > > > > > > > incompatibilities I should watch out for? > > > > > > > > > > > > > > I've not used TortoiseSVN to create a patch, so someone else will > > > have > > > > > > > to comment on this. > > > > > > > > > > > > > > > > > > > create patch should work. Make sure to attach entirely new files too. > > > > > > At rubyforge, add a comment to your patches, so we can distinguish > > > > > > older from newer patches. > > > > > > > > > > > > > > And last - I know that the directory structure will change soon, > > > and > > > > > since > > > > > > > > the generator creates files I imagine I'd want to test that these > > > > > files are > > > > > > > > correctly created. I'd like to write a comprehensive spec, but > > > I'd > > > > > prefer > > > > > > > > not to write it twice (if the directory changes will affect the > > > sample > > > > > rails > > > > > > > > app). Any thoughts on how to proceed here? > > > > > > > > > > > > > > What that is going to look like is totally unknown right now. There > > > > > > > are wide reaching implications in our build - for example, almost > > > all > > > > > > > of the examples on the website, including those for rspec on rails, > > > > > > > get run with "rake pre_commit". This guarantees that the examples > > > > > > > actually work, which is an important feature that I'd not be very > > > > > > > willing to give up. So the existing example app will need to live > > > > > > > somewhere (so we can use it for the documentation), though it is not > > > > > > > necessary for it to live in the same directory structure as the > > > plugin > > > > > > > code. > > > > > > > > > > > > > > Also, some of the specs in > > > > > > > vendor/rspec_on_rails/vendor/plugins/rspec/spec > > > (which > > > > > specify the > > > > > > > plugin) use controllers and views that are assumed to be where they > > > > > > > would normally be in a rails app. In order to move them beneath the > > > > > > > plugin dirs, we'd have to override all of the underlying rails > > > mapping > > > > > > > mojo. The more I think of that, the less sense it makes to me - BUT, > > > > > > > not making that move means that you can't run those specs without > > > > > > > having the specified controllers, helpers, views, etc in their > > > natural > > > > > > > homes. Kinda sucks. > > > > > > > > > > > > > > All of that said, I'm not sure where this is leading, so the best > > > > > > > advice I can offer is to work w/in the existing directory structure > > > > > > > (in trunk) and hope for the best. There's no guarantee any of this > > > > > > > will move anywhere, so why let that impede your work now? > > > > > > > > > > > > > > > Thanks in advance for your time, > > > > > > > > > > > > > > And for yours! > > > > > > > > > > > > > > Cheers, > > > > > > > David > > > > > > > > > > > > > > > > > > > > > > > Jeff > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > rspec-devel mailing list > > > > > > > > rspec-devel at rubyforge.org > > > > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > rspec-devel mailing list > > > > > > > rspec-devel at rubyforge.org > > > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > _______________________________________________ > > > > > > rspec-devel mailing list > > > > > > rspec-devel at rubyforge.org > > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > rspec-devel mailing list > > > > > rspec-devel at rubyforge.org > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > > _______________________________________________ > > > > rspec-devel mailing list > > > > rspec-devel at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > _______________________________________________ > > > rspec-devel mailing list > > > rspec-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dchelimsky at gmail.com Tue Oct 31 08:17:58 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 31 Oct 2006 08:17:58 -0500 Subject: [rspec-devel] Wider context for RSpec: GUI testing? In-Reply-To: <8d961d900610310032s5ece19d5x8f0651c9f3919193@mail.gmail.com> References: <57c63afe0610301858k794df6eel928840d9a2027933@mail.gmail.com> <8d961d900610310032s5ece19d5x8f0651c9f3919193@mail.gmail.com> Message-ID: <57c63afe0610310517u72781336u6a508373b91413a9@mail.gmail.com> On 10/31/06, aslak hellesoy wrote: > On 10/31/06, David Chelimsky wrote: > > On 10/30/06, Ian Dees wrote: > > > Hi, all. > > > > > > I love RSpec's ease of expressing an author's desired behavior for > > > software. That got me thinking about a little wider context (pun > > > unintended) for the meaning of "behavior." It seems like the sweet > > > spot for RSpec is unit testing of Ruby classes (perhaps including > > > Rails models and controllers). > > > > That may be its sweet spot, but BDD can be top to bottom proposition, > > and we'd like to support that in the long run. > > > > >But here in the office, we're also > > > beginning to find it useful for specifying GUI behavior. > > > > Sweet! > > > > > Of course, now that we're outside the original BDD roots of RSpec, > > > > We really need to talk about this! > > > > > there are some philosophical questions, many of which boil down to, > > > "What's the best way of selectively enabling/disabling certain tests?" > > > where "best" means, "most RSpec-like?" > > > > Now you're talking! > > > > > > > > Let me give you two examples: > > > > > > 1) For localized applications, some tests might be written cleverly > > > enough to work in _any_ language build of the software, while other > > > tests might be language-specific (maybe they depend on a GUI element > > > having a certain caption, and its identity can't be deduced by any > > > other method). > > > > > > 2) Some GUI tests might require at least partial manual intervention; > > > it would be nice to skip these tests when running an overnight, > > > batch-mode test. > > > > > > I can imagine a few different approaches in RSpec: > > > > > > 1) I could separate the tests into different files by my selection > > > criteria: put the English-only tests in their own file, or put the > > > partially manual tests in their own file. The main downside here is > > > that sometimes the most logical way to group tests isn't necessarily > > > by language or degree of automation. > > > > > > 2) I could extend RSpec (thanks, Ruby!) to allow me to specify > > > optional criteria for a context, something like: > > > > > > context "The Borfin", :interactive => :true do > > > specify "should not go shlump after Mr. Bix un-shlumps it" do > > > # drive the GUI and maybe prompt the tester to do physical stuff > > > end > > > end > > > > > > 3) Like #2 above, but for individual specifications instead of contexts. > > > > > > I lean toward #2, but I wanted to bounce my question off the RSpec > > > devels, since the list archives reveal that you have been thinking a > > > great deal about the semantics of tests. > > > > > > What I _don't_ want to do is pollute RSpec with a bunch of GUI testing > > > cruft. It would be nice to use RSpec in this new domain without > > > compromising its simplicity in its primary domain. Again, though, > > > that's where Ruby's open classes sure come in handy. > > > > How about this? We add a spec command option that allows you to set a > > series of one or more key/value pairs: > > > > -i or --include > > > > spec -i":lingua => 'portugu?s', :lingua => 'fran?ais'" > > > > That would run only specs or contexts set up like so: > > > > context "blah in portuguese", :lingua => 'portugu?s' do > > ... > > end > > > > context "..." do > > specify "blah in french", :lingua => 'fran?ais' do > > ... > > end > > end > > > > This could be used for all sorts of suite organization, and can be > > automated through rake tasks. > > > > Sound like a good approach? > > > > Interesting, but it sounds somewhat redundant to the -s option. They are related, and maybe we can just add this capability to the -s option, but the key/value pair thing lets you group things together quite arbitrarily, while the -s option is based solely on the name of the context and/or spec. The arbitrary grouping allows you to separate the concern of how to organize specs vis a vis behaviour and other types of organization. A perfect example is our other thread about having certain specs run against the current rails release while others run against both the current release and edge-rails. We could solve the problem by wrapping the specs in conditionals, as you proposed earlier but I think that this feature would provide a simpler mechanism for doing the same thing. Not simpler inside rspec, but easier to use. > > > David > > > > > > > > > > Thanks in advance for your thoughts. > > > > > > Sincerely, > > > > > > Ian Dees > > > _______________________________________________ > > > rspec-devel mailing list > > > rspec-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dchelimsky at gmail.com Tue Oct 31 08:21:22 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 31 Oct 2006 08:21:22 -0500 Subject: [rspec-devel] Spec a spec generator In-Reply-To: <8d961d900610310133k1b6ebe35haf548fb14ce6142a@mail.gmail.com> References: <246e442a0610300006n5babb1d1wd22d538fa056d4a5@mail.gmail.com> <57c63afe0610300123l4d068972h6adc30b9171b29df@mail.gmail.com> <8d961d900610300543o57e87bd3r4828f1347f5fdc82@mail.gmail.com> <246e442a0610301356x3e965c0cxe36384b31f757b20@mail.gmail.com> <8d961d900610301513m42cb1984pb843b919432a2dc4@mail.gmail.com> <246e442a0610301702l64446cf2p6f99e59836e7de63@mail.gmail.com> <8d961d900610301742h195dafc8u264db30947c66eab@mail.gmail.com> <57c63afe0610301904q61a09377q55af10b7a90e9f8a@mail.gmail.com> <8d961d900610310133k1b6ebe35haf548fb14ce6142a@mail.gmail.com> Message-ID: <57c63afe0610310521x2d423b64r21b6dc99f72f829d@mail.gmail.com> On 10/31/06, aslak hellesoy wrote: > On 10/31/06, David Chelimsky wrote: > > On 10/30/06, aslak hellesoy wrote: > > > On 10/31/06, Jeff Dean wrote: > > > > "ruby script/generate rspec" did the trick for getting the specs to start > > > > running, but now I'm getting an error and after looking through each of the > > > > files, I still can't figure out what the problem is. > > > > > > > > D:/rails/rspec/vendor/rspec_on_rails/vendor/plugins/rspec/lib/extensions/test/rails.rb > > > > line 1 is: > > > > > > > > require 'test/rails'This seems to be trying to require itself and I don't > > > > know if that is correct or if it should be pointing to somewhere else. > > > > > > > > > > It's not trying to include itself, it's trying to include a file from > > > zentest (on which rspec on rails has a dependency) > > > > > > gem install ZenTest > > > > > > should get you further > > > > Ah yes. The new plugin extends (and therefore depends on) ZenTest. > > This is something that will be well documented prior to the release. > > > > I've surrounded the require code ina begin/rescue that will tell you > that explicitly in case people don't RTFM ;-) Great idea. Thanks! > > > > > > > > I'll keep looking through this, and any help would be appreciated. Here's > > > > the error message: > > > > > > > > C:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > > > `gem_original_require': no such file to load -- test/rails > > > > (MissingSourceFile) > > > > from > > > > C:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > > > `require' > > > > from > > > > D:/rails/rspec/vendor/rspec_on_rails/config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:400:in > > > > `require' > > > > from > > > > D:/rails/rspec/vendor/rspec_on_rails/vendor/plugins/rspec/lib/extensions/test/rails.rb:1 > > > > from > > > > C:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > > > `require' > > > > from > > > > D:/rails/rspec/vendor/rspec_on_rails/config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:400:in > > > > `require' > > > > from > > > > D:/rails/rspec/vendor/rspec_on_rails/config/../vendor/plugins/rspec/lib/rspec_on_rails.rb:16 > > > > from > > > > C:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > > > `require' > > > > from > > > > D:/rails/rspec/vendor/rspec_on_rails/config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:400:in > > > > `require' > > > > from > > > > ./vendor/plugins/rspec/spec/../../../../spec/spec_helper.rb:3 > > > > from > > > > C:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > > > `require' > > > > from ./vendor/plugins/rspec/spec/spec_helper.rb:1 > > > > from > > > > C:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > > > `require' > > > > from > > > > ./vendor/plugins/rspec/spec/context_factory_spec.rb:1 > > > > from > > > > C:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > > > `require' > > > > from D:/rails/rspec/bin/spec:14 > > > > from D:/rails/rspec/bin/spec:8 > > > > > > > > Jeff > > > > > > > > > > > > On 10/30/06, aslak hellesoy < aslak.hellesoy at gmail.com> wrote: > > > > > On 10/30/06, Jeff Dean < jeff at jefdean.com> wrote: > > > > > > I just tried to run rake spec:plugins from trunk and got the following > > > > error > > > > > > message. I have the 0.6.4 gem installed. > > > > > > > > > > > > D:\rails\rspec\vendor\rspec_on_rails>rake spec:plugins > > > > > > (in D:/rails/rspec/vendor/rspec_on_rails) > > > > > > c:/ruby/bin/ruby -I"D:/rails/rspec/lib" "D:/rails/rspec/bin/spec" > > > > > > "vendor/plugins/rspec/spec/context_factory_spec.rb" > > > > > > > > > > "vendor/plugins/rspec/spec/controller_isolation_spec.rb" > > > > > > "vendor/plugins/rspec/spe > > > > > > c/opts_merger_spec.rb" > > > > > > > > > > "vendor/plugins/rspec/spec/expectations/should_be_spec.rb" > > > > > > > > > > "vendor/plugins/rspec/spec/expectations/should_have_rjs_spec.rb" > > > > > > "vendor/plugins/rspec/spec/expectations/should_have_t > > > > > > ag_spec.rb" > > > > > > > > > > "vendor/plugins/rspec/spec/expectations/should_not_have_rjs_spec.rb" > > > > > > > > > > "vendor/plugins/rspec/spec/expectations/should_not_have_tag_spec.rb" > > > > > > "vendor/plugins/rspec/spec/expectations/should_not > > > > > > _render_rjs_spec.rb" > > > > > > > > > > "vendor/plugins/rspec/spec/expectations/should_render_rjs_spec.rb" > > > > > > > > > > "vendor/plugins/rspec/spec/expectations/should_render_spec.rb" > > > > > > "vendor/plugins/rspec/spec/generators/rspec_resou > > > > > > rce_scaffold_spec.rb" > > > > > > > > > > c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > > > > > `gem_original_require': no such file to load -- controller_mixin > > > > > > (MissingSourceFile) > > > > > > from > > > > > > > > > > c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > > > > > `require' > > > > > > from > > > > > > > > > > D:/rails/rspec/vendor/rspec_on_rails/config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:400:in > > > > > > `require' > > > > > > from > > > > > > > > > > ./vendor/plugins/rspec/spec/../../../../spec/spec_helper.rb:3 > > > > > > from > > > > > > > > > > c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > > > > > `require' > > > > > > from > > > > ./vendor/plugins/rspec/spec/spec_helper.rb:1 > > > > > > from > > > > > > > > > > c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > > > > > `require' > > > > > > from > > > > > > ./vendor/plugins/rspec/spec/context_factory_spec.rb:1 > > > > > > from > > > > > > > > > > c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > > > > > > `require' > > > > > > from D:/rails/rspec/bin/spec:14 > > > > > > from D:/rails/rspec/bin/spec:8 > > > > > > rake aborted! > > > > > > Command failed with status (1): [c:/ruby/bin/ruby -I"D:/rails/rspec/lib" > > > > > > "D...] > > > > > > > > > > > > Do I have to uninstall the gem to make this work? > > > > > > > > > > > > > > > > No, but you have to re-bootstrap the rails project by first running: > > > > > > > > > > ruby script/generate rspec > > > > > > > > > > Aslak > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 10/30/06, aslak hellesoy wrote: > > > > > > > On 10/30/06, David Chelimsky < dchelimsky at gmail.com> wrote: > > > > > > > > On 10/30/06, Jeff Dean wrote: > > > > > > > > > I just created an rspec_scaffold_resource generator and I've got a > > > > few > > > > > > > > > questions about what the next steps are. > > > > > > > > > > > > > > > > > > First, this is a total noob question, but how do I run the specs > > > > from > > > > > > > > > > > > > rspec/vendor/rspec_on_rails/vendor/plugins/rspec/spec > > > > > > from > > > > > > > > > the command line? I haven't written specs for the generator yet > > > > > > because I > > > > > > > > > don't know how to run them. > > > > > > > > > > > > > > > > Assuming you've checked out the source and have all the > > > > dependencies, > > > > > > > > stand in vendor/rspec_on_rails and say "rake spec:plugins" or > > > > > > > > "../../bin/spec vendor/plugins/rspec/spec". > > > > > > > > > > > > > > > > > > > > > > > > > > Second, rspec_scaffold_resource depends on edge rails. Is it safe > > > > to > > > > > > assume > > > > > > > > > that if you are running rspec_scaffold_resource that you are > > > > already > > > > > > running > > > > > > > > > edge, or should I try to check for it somehow? On a related note > > > > - > > > > > > since > > > > > > > > > you can't run it without edge, you need to freeze edge or add an > > > > > > > > > svn:externals property to even try it out. > > > > > > > > > > > > > > > > > > > > > > For now, just assume edge rails is available. > > > > > > > > > > > > > > > This is something I hadn't considered. We don't have any official > > > > > > > > support policy, and given that nobody working on this does so full > > > > > > > > time, any such policy would have to take that into account. The most > > > > > > > > reasonable policy I can think of is that we should do our best to > > > > > > > > ensuring that any rspec release works w/ the latest rails stable > > > > > > > > release at the time. This would, obviously, not pertain to edge > > > > rails. > > > > > > > > Maybe some day enough people will use rspec on rails and the rails > > > > > > > > core team will have the good sense to incorporate this functionality > > > > > > > > right into rails (you can say-ay-ay I'm a dreamer.....). > > > > > > > > > > > > > > > > In the mean time, this does present an interesting dilemma. What if > > > > we > > > > > > > > were to set up the build so that running "rake pre_commit" will run > > > > > > > > everything but these edge-rails-specific specs against the latest > > > > > > > > stable rails and fail the build if anything fails, but then run > > > > > > > > everything including the edge-rails-specific specs and only report > > > > if > > > > > > > > anything fails, but still pass the build? That would keep us > > > > > > > > progressing without turning edge rails into a bottleneck, but would > > > > > > > > also keep edge rails constantly on the radar. > > > > > > > > > > > > > > > > If that makes sense to everyone, I'm sure we can figure out a way to > > > > do > > > > > > it. > > > > > > > > > > > > > > > > > > > > > > A script that specifies an array of svn tags and trunk. E.g. > > > > > > > ['tags/1.1.6', 'trunk'] > > > > > > > We'd loop through this array and run rake spec for all of them. > > > > > > > > > > > > > > Each spec could have its body in an if block a la: > > > > > > > > > > > > > > if(RAILS_VERSION > 1.1.6) > > > > > > > specify "something that should only work on edge" do > > > > > > > ... > > > > > > > end > > > > > > > end > > > > > > > > > > > > > > > > Third, I'm not too experienced with patching, but I assume that > > > > the > > > > > > > > > TortosieSVN's "create patch" and specifying all of the > > > > new/modified > > > > > > files > > > > > > > > > should do the trick. Is there anything else I should know? Any > > > > > > > > > incompatibilities I should watch out for? > > > > > > > > > > > > > > > > I've not used TortoiseSVN to create a patch, so someone else will > > > > have > > > > > > > > to comment on this. > > > > > > > > > > > > > > > > > > > > > > create patch should work. Make sure to attach entirely new files too. > > > > > > > At rubyforge, add a comment to your patches, so we can distinguish > > > > > > > older from newer patches. > > > > > > > > > > > > > > > > And last - I know that the directory structure will change soon, > > > > and > > > > > > since > > > > > > > > > the generator creates files I imagine I'd want to test that these > > > > > > files are > > > > > > > > > correctly created. I'd like to write a comprehensive spec, but > > > > I'd > > > > > > prefer > > > > > > > > > not to write it twice (if the directory changes will affect the > > > > sample > > > > > > rails > > > > > > > > > app). Any thoughts on how to proceed here? > > > > > > > > > > > > > > > > What that is going to look like is totally unknown right now. There > > > > > > > > are wide reaching implications in our build - for example, almost > > > > all > > > > > > > > of the examples on the website, including those for rspec on rails, > > > > > > > > get run with "rake pre_commit". This guarantees that the examples > > > > > > > > actually work, which is an important feature that I'd not be very > > > > > > > > willing to give up. So the existing example app will need to live > > > > > > > > somewhere (so we can use it for the documentation), though it is not > > > > > > > > necessary for it to live in the same directory structure as the > > > > plugin > > > > > > > > code. > > > > > > > > > > > > > > > > Also, some of the specs in > > > > > > > > vendor/rspec_on_rails/vendor/plugins/rspec/spec > > > > (which > > > > > > specify the > > > > > > > > plugin) use controllers and views that are assumed to be where they > > > > > > > > would normally be in a rails app. In order to move them beneath the > > > > > > > > plugin dirs, we'd have to override all of the underlying rails > > > > mapping > > > > > > > > mojo. The more I think of that, the less sense it makes to me - BUT, > > > > > > > > not making that move means that you can't run those specs without > > > > > > > > having the specified controllers, helpers, views, etc in their > > > > natural > > > > > > > > homes. Kinda sucks. > > > > > > > > > > > > > > > > All of that said, I'm not sure where this is leading, so the best > > > > > > > > advice I can offer is to work w/in the existing directory structure > > > > > > > > (in trunk) and hope for the best. There's no guarantee any of this > > > > > > > > will move anywhere, so why let that impede your work now? > > > > > > > > > > > > > > > > > Thanks in advance for your time, > > > > > > > > > > > > > > > > And for yours! > > > > > > > > > > > > > > > > Cheers, > > > > > > > > David > > > > > > > > > > > > > > > > > > > > > > > > > > Jeff > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > rspec-devel mailing list > > > > > > > > > rspec-devel at rubyforge.org > > > > > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > rspec-devel mailing list > > > > > > > > rspec-devel at rubyforge.org > > > > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > rspec-devel mailing list > > > > > > > rspec-devel at rubyforge.org > > > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > rspec-devel mailing list > > > > > > rspec-devel at rubyforge.org > > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > rspec-devel mailing list > > > > > rspec-devel at rubyforge.org > > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > > > > > > > _______________________________________________ > > > > rspec-devel mailing list > > > > rspec-devel at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > > > _______________________________________________ > > > rspec-devel mailing list > > > rspec-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From aslak.hellesoy at gmail.com Tue Oct 31 09:25:10 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Tue, 31 Oct 2006 15:25:10 +0100 Subject: [rspec-devel] Wider context for RSpec: GUI testing? In-Reply-To: <57c63afe0610310517u72781336u6a508373b91413a9@mail.gmail.com> References: <57c63afe0610301858k794df6eel928840d9a2027933@mail.gmail.com> <8d961d900610310032s5ece19d5x8f0651c9f3919193@mail.gmail.com> <57c63afe0610310517u72781336u6a508373b91413a9@mail.gmail.com> Message-ID: <8d961d900610310625x565797d0nae1bbe5fd660c86@mail.gmail.com> On 10/31/06, David Chelimsky wrote: > On 10/31/06, aslak hellesoy wrote: > > On 10/31/06, David Chelimsky wrote: > > > On 10/30/06, Ian Dees wrote: > > > > Hi, all. > > > > > > > > I love RSpec's ease of expressing an author's desired behavior for > > > > software. That got me thinking about a little wider context (pun > > > > unintended) for the meaning of "behavior." It seems like the sweet > > > > spot for RSpec is unit testing of Ruby classes (perhaps including > > > > Rails models and controllers). > > > > > > That may be its sweet spot, but BDD can be top to bottom proposition, > > > and we'd like to support that in the long run. > > > > > > >But here in the office, we're also > > > > beginning to find it useful for specifying GUI behavior. > > > > > > Sweet! > > > > > > > Of course, now that we're outside the original BDD roots of RSpec, > > > > > > We really need to talk about this! > > > > > > > there are some philosophical questions, many of which boil down to, > > > > "What's the best way of selectively enabling/disabling certain tests?" > > > > where "best" means, "most RSpec-like?" > > > > > > Now you're talking! > > > > > > > > > > > Let me give you two examples: > > > > > > > > 1) For localized applications, some tests might be written cleverly > > > > enough to work in _any_ language build of the software, while other > > > > tests might be language-specific (maybe they depend on a GUI element > > > > having a certain caption, and its identity can't be deduced by any > > > > other method). > > > > > > > > 2) Some GUI tests might require at least partial manual intervention; > > > > it would be nice to skip these tests when running an overnight, > > > > batch-mode test. > > > > > > > > I can imagine a few different approaches in RSpec: > > > > > > > > 1) I could separate the tests into different files by my selection > > > > criteria: put the English-only tests in their own file, or put the > > > > partially manual tests in their own file. The main downside here is > > > > that sometimes the most logical way to group tests isn't necessarily > > > > by language or degree of automation. > > > > > > > > 2) I could extend RSpec (thanks, Ruby!) to allow me to specify > > > > optional criteria for a context, something like: > > > > > > > > context "The Borfin", :interactive => :true do > > > > specify "should not go shlump after Mr. Bix un-shlumps it" do > > > > # drive the GUI and maybe prompt the tester to do physical stuff > > > > end > > > > end > > > > > > > > 3) Like #2 above, but for individual specifications instead of contexts. > > > > > > > > I lean toward #2, but I wanted to bounce my question off the RSpec > > > > devels, since the list archives reveal that you have been thinking a > > > > great deal about the semantics of tests. > > > > > > > > What I _don't_ want to do is pollute RSpec with a bunch of GUI testing > > > > cruft. It would be nice to use RSpec in this new domain without > > > > compromising its simplicity in its primary domain. Again, though, > > > > that's where Ruby's open classes sure come in handy. > > > > > > How about this? We add a spec command option that allows you to set a > > > series of one or more key/value pairs: > > > > > > -i or --include > > > > > > spec -i":lingua => 'portugu?s', :lingua => 'fran?ais'" > > > > > > That would run only specs or contexts set up like so: > > > > > > context "blah in portuguese", :lingua => 'portugu?s' do > > > ... > > > end > > > > > > context "..." do > > > specify "blah in french", :lingua => 'fran?ais' do > > > ... > > > end > > > end > > > > > > This could be used for all sorts of suite organization, and can be > > > automated through rake tasks. > > > > > > Sound like a good approach? > > > > > > > Interesting, but it sounds somewhat redundant to the -s option. > > They are related, and maybe we can just add this capability to the -s > option, but the key/value pair thing lets you group things together > quite arbitrarily, while the -s option is based solely on the name of > the context and/or spec. The arbitrary grouping allows you to separate > the concern of how to organize specs vis a vis behaviour and other > types of organization. > > A perfect example is our other thread about having certain specs run > against the current rails release while others run against both the > current release and edge-rails. We could solve the problem by wrapping > the specs in conditionals, as you proposed earlier but I think that > this feature would provide a simpler mechanism for doing the same > thing. Not simpler inside rspec, but easier to use. > Agreed. Let's explore it post 0.7.0 Aslak > > > > > > > > David > > > > > > > > > > > > > > Thanks in advance for your thoughts. > > > > > > > > Sincerely, > > > > > > > > Ian Dees > > > > _______________________________________________ > > > > rspec-devel mailing list > > > > rspec-devel at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > _______________________________________________ > > > rspec-devel mailing list > > > rspec-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From luke at agileevolved.com Mon Oct 30 04:05:41 2006 From: luke at agileevolved.com (Luke Redpath) Date: Mon, 30 Oct 2006 09:05:41 +0000 Subject: [rspec-devel] (no subject) Message-ID: <5FB2794B-4E6A-42C3-A5B8-F3A6BE3D04EA@agileevolved.com> Hi Everybody, Sorry if this ends up x-posted, I'm not sure if my post to rspec- users showed up (I don't think I'm subscribed to that list--doh!). I've started using RSpec more and more recently and seeing as I use the best editor in the world ( *flamebait* ;-; ) I've put together a pretty comprehensive TextMate bundle for Rails. This contains lots of snippets for all of the expectations, plus support for Rails-specific features and file templates. You can check the bundle out from Subversion into your TextMate Bundles folder. The bundle is here: http://opensource.agileevolved.com/svn/root/textmate/bundles/ RSpec.tmbundle/ Any feedback or suggestions are welcomed. If you TextMate then I hope that this makes your BDD sessions a bit easier! Cheers Luke Redpath www.lukeredpath.co.uk From luke at agileevolved.com Tue Oct 31 10:09:49 2006 From: luke at agileevolved.com (Luke Redpath) Date: Tue, 31 Oct 2006 15:09:49 +0000 Subject: [rspec-devel] RSpec Textmate bundle (was [no subject]) In-Reply-To: <5FB2794B-4E6A-42C3-A5B8-F3A6BE3D04EA@agileevolved.com> References: <5FB2794B-4E6A-42C3-A5B8-F3A6BE3D04EA@agileevolved.com> Message-ID: <57B2279B-AF50-482E-BB9B-26CAF062523E@agileevolved.com> Sorry about the no subject...doh! On 30 Oct 2006, at 09:05, Luke Redpath wrote: > Hi Everybody, > > Sorry if this ends up x-posted, I'm not sure if my post to rspec- > users showed up (I don't think I'm subscribed to that list--doh!). > > I've started using RSpec more and more recently and seeing as I use > the best editor in the world ( *flamebait* ;-; ) I've put together a > pretty comprehensive TextMate bundle for Rails. This contains lots of > snippets for all of the expectations, plus support for Rails-specific > features and file templates. > > You can check the bundle out from Subversion into your TextMate > Bundles folder. The bundle is here: > > http://opensource.agileevolved.com/svn/root/textmate/bundles/ > RSpec.tmbundle/ > > Any feedback or suggestions are welcomed. If you TextMate then I hope > that this makes your BDD sessions a bit easier! > > Cheers > Luke Redpath > www.lukeredpath.co.uk > > _______________________________________________ > 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/20061031/3a496bce/attachment.html From jrich013 at gmail.com Tue Oct 31 10:20:09 2006 From: jrich013 at gmail.com (Justin Rich) Date: Tue, 31 Oct 2006 10:20:09 -0500 Subject: [rspec-devel] (no subject) In-Reply-To: <5FB2794B-4E6A-42C3-A5B8-F3A6BE3D04EA@agileevolved.com> References: <5FB2794B-4E6A-42C3-A5B8-F3A6BE3D04EA@agileevolved.com> Message-ID: Luke, Thanks for the bundle....I do like the Rails templates, very cool. I did notice one small problem though, in the Context snippet, the scope is set to be 'source.rub' instead of 'source.ruby'. Hope that helps. -------------------------------------------- name Context scope source.rub tabTrigger con uuid 1AEC727D-CE27-4A36-AD41-F76C843DAC2B -Justin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061031/8b76d86e/attachment.html From luke at agileevolved.com Mon Oct 30 05:58:55 2006 From: luke at agileevolved.com (Luke Redpath) Date: Mon, 30 Oct 2006 10:58:55 +0000 Subject: [rspec-devel] [ANN] RSpec TextMate Bundle Message-ID: <03661C90-1368-4E30-B62B-8613D379945D@agileevolved.com> Hi Everybody, Sorry if this ends up x-posted, I'm not sure if my post to rspec- users showed up (I don't think I'm subscribed to that list--doh!). I've started using RSpec more and more recently and seeing as I use the best editor in the world ( *flamebait* ;-; ) I've put together a pretty comprehensive TextMate bundle for Rails. This contains lots of snippets for all of the expectations, plus support for Rails-specific features and file templates. You can check the bundle out from Subversion into your TextMate Bundles folder. The bundle is here: http://opensource.agileevolved.com/svn/root/textmate/bundles/ RSpec.tmbundle/ Any feedback or suggestions are welcomed. If you TextMate then I hope that this makes your BDD sessions a bit easier! Cheers Luke Redpath www.lukeredpath.co.uk From luke at agileevolved.com Tue Oct 31 11:29:21 2006 From: luke at agileevolved.com (Luke Redpath) Date: Tue, 31 Oct 2006 16:29:21 +0000 Subject: [rspec-devel] (no subject) In-Reply-To: References: <5FB2794B-4E6A-42C3-A5B8-F3A6BE3D04EA@agileevolved.com> Message-ID: Hi Justin Well spotted, I'll fix and check in now. Cheers Luke On 31 Oct 2006, at 15:20, Justin Rich wrote: > Luke, > > Thanks for the bundle....I do like the Rails templates, very cool. > > I did notice one small problem though, in the Context snippet, the > scope is set to be 'source.rub' instead of 'source.ruby'. Hope that > helps. > > -------------------------------------------- > name > Context > scope > source.rub > tabTrigger > con > uuid > 1AEC727D-CE27-4A36-AD41-F76C843DAC2B > > -Justin > _______________________________________________ > 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/20061031/a9aa82f6/attachment-0001.html From luke at agileevolved.com Tue Oct 31 11:31:00 2006 From: luke at agileevolved.com (Luke Redpath) Date: Tue, 31 Oct 2006 16:31:00 +0000 Subject: [rspec-devel] [ANN] RSpec TextMate Bundle In-Reply-To: <03661C90-1368-4E30-B62B-8613D379945D@agileevolved.com> References: <03661C90-1368-4E30-B62B-8613D379945D@agileevolved.com> Message-ID: Again, sorry for the double post - I've been having a few mail problems. Cheers Luke On 30 Oct 2006, at 10:58, Luke Redpath wrote: > Hi Everybody, > > Sorry if this ends up x-posted, I'm not sure if my post to rspec- > users showed up (I don't think I'm subscribed to that list--doh!). > > I've started using RSpec more and more recently and seeing as I use > the best editor in the world ( *flamebait* ;-; ) I've put together a > pretty comprehensive TextMate bundle for Rails. This contains lots of > snippets for all of the expectations, plus support for Rails-specific > features and file templates. > > You can check the bundle out from Subversion into your TextMate > Bundles folder. The bundle is here: > > http://opensource.agileevolved.com/svn/root/textmate/bundles/ > RSpec.tmbundle/ > > Any feedback or suggestions are welcomed. If you TextMate then I hope > that this makes your BDD sessions a bit easier! > > Cheers > Luke Redpath > www.lukeredpath.co.uk > > _______________________________________________ > 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/20061031/8f648396/attachment.html From dastels at daveastels.com Tue Oct 31 11:40:09 2006 From: dastels at daveastels.com (Dave Astels) Date: Tue, 31 Oct 2006 12:40:09 -0400 Subject: [rspec-devel] [ANN] RSpec TextMate Bundle In-Reply-To: <03661C90-1368-4E30-B62B-8613D379945D@agileevolved.com> References: <03661C90-1368-4E30-B62B-8613D379945D@agileevolved.com> Message-ID: <71D979D4-B8D1-4F07-88B7-986C72E19224@daveastels.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 30-Oct-06, at 6:58 AM, Luke Redpath wrote: > > Any feedback or suggestions are welcomed. If you TextMate then I hope > that this makes your BDD sessions a bit easier! One suggestion for the snippet for specify.. specify "should ${1:description}" do $0 end Dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFFR3xpauez/L4x7g4RApXDAKCtHglmvV+FmN5DtGQr92T8X4t5CQCfS73Q Tz0UmDOSr3EURqB6Urxkrhs= =mUGx -----END PGP SIGNATURE----- From bkeepers at gmail.com Tue Oct 31 11:57:31 2006 From: bkeepers at gmail.com (Brandon Keepers) Date: Tue, 31 Oct 2006 11:57:31 -0500 Subject: [rspec-devel] (no subject) In-Reply-To: <5FB2794B-4E6A-42C3-A5B8-F3A6BE3D04EA@agileevolved.com> References: <5FB2794B-4E6A-42C3-A5B8-F3A6BE3D04EA@agileevolved.com> Message-ID: Luke, This is great. I've been using rspec on my rails projects for the past several weeks, and lack of textmate support was really annoying. Thanks a ton! Brandon From luke at agileevolved.com Tue Oct 31 12:16:22 2006 From: luke at agileevolved.com (Luke Redpath) Date: Tue, 31 Oct 2006 17:16:22 +0000 Subject: [rspec-devel] [ANN] RSpec TextMate Bundle In-Reply-To: <71D979D4-B8D1-4F07-88B7-986C72E19224@daveastels.com> References: <03661C90-1368-4E30-B62B-8613D379945D@agileevolved.com> <71D979D4-B8D1-4F07-88B7-986C72E19224@daveastels.com> Message-ID: <3FC7E7CE-9D93-498F-9F8C-B4E50B8001B2@agileevolved.com> Good suggestion Dave. I've checked this in. I've implemented it so you can hit tab a second time to select the entire string (in case you want to do something that doesn't begin with should...). Cheers Luke On 31 Oct 2006, at 16:40, Dave Astels wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On 30-Oct-06, at 6:58 AM, Luke Redpath wrote: > >> >> Any feedback or suggestions are welcomed. If you TextMate then I hope >> that this makes your BDD sessions a bit easier! > > One suggestion for the snippet for specify.. > > specify "should ${1:description}" do > $0 > end > > Dave > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.3 (Darwin) > > iD8DBQFFR3xpauez/L4x7g4RApXDAKCtHglmvV+FmN5DtGQr92T8X4t5CQCfS73Q > Tz0UmDOSr3EURqB6Urxkrhs= > =mUGx > -----END PGP SIGNATURE----- > _______________________________________________ > 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/20061031/a6b9cea0/attachment-0001.html From undees at gmail.com Tue Oct 31 12:42:06 2006 From: undees at gmail.com (Ian Dees) Date: Tue, 31 Oct 2006 09:42:06 -0800 Subject: [rspec-devel] Wider context for RSpec: GUI testing? Message-ID: Hi, David and Aslak. Thanks for your thoughts on GUI testing in RSpec. Quoth David: > That may be its sweet spot, but BDD can be top to bottom proposition, > and we'd like to support that in the long run. I'm glad to hear that! I was worried about pushing RSpec in a direction too divergent from its architects' concept. > How about this? We add a spec command option that allows you to set a > series of one or more key/value pairs: > > -i or --include > > spec -i":lingua => 'portugu?s', :lingua => 'fran?ais'" That could be doable. While we're brainstorming, I'll toss out a couple of alternatives, just for fun. How about having some optional constants at module level, like (for my examples) Spec.Lingua and Spec.Batch ? Then, we could have a config file of sorts in Ruby, and pass the -r switch to require that file (thus saving the need to add a new command-line flag). Or even make the options a hash at module level (instead of individual constants), so that it's more extendable in some of the directions David has mentioned, like isolating edge-rails tests. Anyway, I know y'all are gearing up for the 0.7.0 release, so I'll just stay tuned, and maybe we can pick up the discussion again after that. Thanks again for turning your minds to my questions. Sincerely, Ian From david at davelee.com.au Tue Oct 31 16:44:13 2006 From: david at davelee.com.au (David Lee) Date: Wed, 1 Nov 2006 08:44:13 +1100 Subject: [rspec-devel] TextMate bundle (was Re: (no subject) In-Reply-To: References: <5FB2794B-4E6A-42C3-A5B8-F3A6BE3D04EA@agileevolved.com> Message-ID: Hi Luke, Thanks! I haven't actually tried your bundle yet as I don't have my mac here, *but* please allow me to ask beforehand: does it support the shift-cmd-R 'Run Focused Test (er .. spec)' command? that thing rocks my world for Test::Unit look forward to checking this out cheers, David On 01/11/2006, at 3:29 AM, Luke Redpath wrote: > Hi Justin > > Well spotted, I'll fix and check in now. > > Cheers > Luke > > On 31 Oct 2006, at 15:20, Justin Rich wrote: > >> Luke, >> >> Thanks for the bundle....I do like the Rails templates, very cool. >> >> I did notice one small problem though, in the Context snippet, the >> scope is set to be 'source.rub' instead of 'source.ruby'. Hope >> that helps. >> >> -------------------------------------------- >> name >> Context >> scope >> source.rub >> tabTrigger >> con >> uuid >> 1AEC727D-CE27-4A36-AD41-F76C843DAC2B >> >> -Justin >> _______________________________________________ >> rspec-devel mailing list >> rspec-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-devel > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061101/b77832af/attachment.html From luke at agileevolved.com Tue Oct 31 19:15:23 2006 From: luke at agileevolved.com (Luke Redpath) Date: Wed, 1 Nov 2006 00:15:23 +0000 Subject: [rspec-devel] TextMate bundle (was Re: (no subject) In-Reply-To: References: <5FB2794B-4E6A-42C3-A5B8-F3A6BE3D04EA@agileevolved.com> Message-ID: <85AAB0F1-45D1-441C-B51D-D1D84C11A511@agileevolved.com> Hi David Yes, it does. :) It was one of the things I missed from the Ruby bundle too. It also has standard "run all specs" and "run all specs (specdoc mode)". Cheers Luke On 31 Oct 2006, at 21:44, David Lee wrote: > Hi Luke, > > Thanks! > > I haven't actually tried your bundle yet as I don't have my mac > here, *but* > please allow me to ask beforehand: > > does it support the shift-cmd-R 'Run Focused Test (er .. spec)' > command? > > that thing rocks my world for Test::Unit > > look forward to checking this out > > cheers, > David > > > On 01/11/2006, at 3:29 AM, Luke Redpath wrote: > >> Hi Justin >> >> Well spotted, I'll fix and check in now. >> >> Cheers >> Luke >> >> On 31 Oct 2006, at 15:20, Justin Rich wrote: >> >>> Luke, >>> >>> Thanks for the bundle....I do like the Rails templates, very cool. >>> >>> I did notice one small problem though, in the Context snippet, >>> the scope is set to be 'source.rub' instead of 'source.ruby'. >>> Hope that helps. >>> >>> -------------------------------------------- >>> name >>> Context >>> scope >>> source.rub >>> tabTrigger >>> con >>> uuid >>> 1AEC727D-CE27-4A36-AD41-F76C843DAC2B >>> >>> -Justin >>> _______________________________________________ >>> rspec-devel mailing list >>> rspec-devel at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rspec-devel >> >> _______________________________________________ >> rspec-devel mailing list >> rspec-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-devel > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061101/387eb3ed/attachment-0001.html From david at davelee.com.au Tue Oct 31 20:20:09 2006 From: david at davelee.com.au (David Lee) Date: Wed, 1 Nov 2006 12:20:09 +1100 Subject: [rspec-devel] TextMate bundle (was Re: (no subject) In-Reply-To: <85AAB0F1-45D1-441C-B51D-D1D84C11A511@agileevolved.com> References: <5FB2794B-4E6A-42C3-A5B8-F3A6BE3D04EA@agileevolved.com> <85AAB0F1-45D1-441C-B51D-D1D84C11A511@agileevolved.com> Message-ID: <673186E8-BCDD-42A2-A369-F7B92E33689E@davelee.com.au> awesome. between this and the upcoming 0.7 and the focus I'm seeing on improving stability / solidity of the rails plugin, I think I might be moving back to rspec from simply_bdd / Test::Unit ... cheers, David On 01/11/2006, at 11:15 AM, Luke Redpath wrote: > Hi David > > Yes, it does. :) It was one of the things I missed from the Ruby > bundle too. > > It also has standard "run all specs" and "run all specs (specdoc > mode)". > > Cheers > Luke > > On 31 Oct 2006, at 21:44, David Lee wrote: > >> Hi Luke, >> >> Thanks! >> >> I haven't actually tried your bundle yet as I don't have my mac >> here, *but* >> please allow me to ask beforehand: >> >> does it support the shift-cmd-R 'Run Focused Test (er .. spec)' >> command? >> >> that thing rocks my world for Test::Unit >> >> look forward to checking this out >> >> cheers, >> David >> >> >> On 01/11/2006, at 3:29 AM, Luke Redpath wrote: >> >>> Hi Justin >>> >>> Well spotted, I'll fix and check in now. >>> >>> Cheers >>> Luke >>> >>> On 31 Oct 2006, at 15:20, Justin Rich wrote: >>> >>>> Luke, >>>> >>>> Thanks for the bundle....I do like the Rails templates, very cool. >>>> >>>> I did notice one small problem though, in the Context snippet, >>>> the scope is set to be 'source.rub' instead of 'source.ruby'. >>>> Hope that helps. >>>> >>>> -------------------------------------------- >>>> name >>>> Context >>>> scope >>>> source.rub >>>> tabTrigger >>>> con >>>> uuid >>>> 1AEC727D-CE27-4A36-AD41-F76C843DAC2B >>>> >>>> -Justin >>>> _______________________________________________ >>>> rspec-devel mailing list >>>> rspec-devel at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/rspec-devel >>> >>> _______________________________________________ >>> rspec-devel mailing list >>> rspec-devel at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rspec-devel >> >> _______________________________________________ >> rspec-devel mailing list >> rspec-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-devel > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061101/939b3188/attachment.html From dchelimsky at gmail.com Tue Oct 31 20:22:45 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 31 Oct 2006 20:22:45 -0500 Subject: [rspec-devel] revision 1000 Message-ID: <57c63afe0610311722r2e1e177cmed7d7d3562214ba1@mail.gmail.com> Brian Takita committed revision 1000 last night. I don't know what that means - but it seems like an interesting milestone. Congrats to Brian for hitting 1000. Congrats and thank to all of those who have contributed by providing ideas, code, feedback, or simply using rspec and spreading the love. Cheers, David From brian.takita at gmail.com Tue Oct 31 23:23:28 2006 From: brian.takita at gmail.com (Brian Takita) Date: Tue, 31 Oct 2006 20:23:28 -0800 Subject: [rspec-devel] revision 1000 In-Reply-To: <57c63afe0610311722r2e1e177cmed7d7d3562214ba1@mail.gmail.com> References: <57c63afe0610311722r2e1e177cmed7d7d3562214ba1@mail.gmail.com> Message-ID: <1d7ddd110610312023h35098009g83a1210088b38870@mail.gmail.com> On 10/31/06, David Chelimsky wrote: > > Brian Takita committed revision 1000 last night. I don't know what > that means - but it seems like an interesting milestone. > > Congrats to Brian for hitting 1000. Thanks. Sorry for causing you and Aslak to cringe. :) Congrats and thank to all of those who have contributed by providing > ideas, code, feedback, or simply using rspec and spreading the love. > > Cheers, > David > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061031/8d7d2dd5/attachment.html From noreply at rubyforge.org Mon Oct 30 08:33:17 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 Oct 2006 08:33:17 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6396 ] Disabled Specifications and a Yellow build Message-ID: <20061030133318.44A6152415D9@rubyforge.org> Feature Requests item #6396, was opened at 2006-10-30 02:51 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6396&group_id=797 Category: runner module Group: None Status: Open Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: Disabled Specifications and a Yellow build Initial Comment: Add a method that denotes a specification is disabled and causes a yellow build. For example: disable_specify "should support disabled specifications" do end This will be helpful in writing a spec before the feature is implemented. ---------------------------------------------------------------------- Comment By: Jay Levitt (jaylev) Date: 2006-10-30 08:33 Message: +1 for implement ---------------------------------------------------------------------- Comment By: Mike Vincent (agile) Date: 2006-10-30 08:07 Message: The suggested "implement" placeholder would be pretty cool. I have generally started fleshing out specs on rails based projects by flurrying through the model specs spewing out minimal specify statements for the limited things I know about them. Usually just throwing in violations as I'm flying through. Then I start running the specs and going through adding the contraints and going for green. It's a pretty noisy "todo" list when running the specs to find the placeholders. It'd be nice to have a more aesthetically pleasing "todo list" to work from. :) But I concur that being able to turn a real spec yellow probably isn't the behavior we're looking for. rake spec:implement or something that produced a spec:doc like format or something would be pretty nice. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-10-30 07:12 Message: FWIW - Irony of ironies, there is currently an abhorrently commented out spec in the trunk. And *I'm* the one who put it there. Even still, I'd rather do so and feel a little dirty about it than have the tool make me feel clean. Or even just a little yellow. Cheers, David ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-10-30 04:57 Message: Writing an entire specify block before a feature is implemented is not what BDD is about. It goes against the red/green/refactor cycle of TDD, which sits at the heart of BDD. For what it's worth, there is a similar feature in NUnit. I don't believe that I've ever seen it used to allow tests to be ignored in advance of implementation. I've only ever seen it used to ignore existing tests that had been passing and were now failing. Worse, I've seen this cause yellow to become the new green (i.e. an acceptable state for commits and sometimes even releases). Absolutely vile. That said, making decisions about behaviour in advance of implementation is very much aligned w/ BDD, even TDD. What would you think about something like this: implement "should support placeholders for yet to exist specs" This would not accept a block. In fact it would raise if you try to give it one. This way you could write placeholders for specs you know you want, but not allow you to put any code in them. Then there could be a command line option that allows you to report on yet-to-implement specs. Of course, if you insist on violating one of the most basic principles of BDD, you can write up your spec code and comment it out. The commented code would be in a logical place, but the tool would not be condoning the practice. Thoughts? David ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2006-10-30 02:57 Message: I submitted this. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6396&group_id=797 From noreply at rubyforge.org Mon Oct 30 19:18:11 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 Oct 2006 19:18:11 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6396 ] Disabled Specifications and a Yellow build Message-ID: <20061031001811.D0E4EA970006@rubyforge.org> Feature Requests item #6396, was opened at 2006-10-30 02:51 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6396&group_id=797 Category: runner module Group: None Status: Open Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: Disabled Specifications and a Yellow build Initial Comment: Add a method that denotes a specification is disabled and causes a yellow build. For example: disable_specify "should support disabled specifications" do end This will be helpful in writing a spec before the feature is implemented. ---------------------------------------------------------------------- >Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-30 19:18 Message: how about todo "something that needs doing" instead of implement "something that needs doing" because implement is really just a todo - isn't it? ---------------------------------------------------------------------- Comment By: Jay Levitt (jaylev) Date: 2006-10-30 08:33 Message: +1 for implement ---------------------------------------------------------------------- Comment By: Mike Vincent (agile) Date: 2006-10-30 08:07 Message: The suggested "implement" placeholder would be pretty cool. I have generally started fleshing out specs on rails based projects by flurrying through the model specs spewing out minimal specify statements for the limited things I know about them. Usually just throwing in violations as I'm flying through. Then I start running the specs and going through adding the contraints and going for green. It's a pretty noisy "todo" list when running the specs to find the placeholders. It'd be nice to have a more aesthetically pleasing "todo list" to work from. :) But I concur that being able to turn a real spec yellow probably isn't the behavior we're looking for. rake spec:implement or something that produced a spec:doc like format or something would be pretty nice. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-10-30 07:12 Message: FWIW - Irony of ironies, there is currently an abhorrently commented out spec in the trunk. And *I'm* the one who put it there. Even still, I'd rather do so and feel a little dirty about it than have the tool make me feel clean. Or even just a little yellow. Cheers, David ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-10-30 04:57 Message: Writing an entire specify block before a feature is implemented is not what BDD is about. It goes against the red/green/refactor cycle of TDD, which sits at the heart of BDD. For what it's worth, there is a similar feature in NUnit. I don't believe that I've ever seen it used to allow tests to be ignored in advance of implementation. I've only ever seen it used to ignore existing tests that had been passing and were now failing. Worse, I've seen this cause yellow to become the new green (i.e. an acceptable state for commits and sometimes even releases). Absolutely vile. That said, making decisions about behaviour in advance of implementation is very much aligned w/ BDD, even TDD. What would you think about something like this: implement "should support placeholders for yet to exist specs" This would not accept a block. In fact it would raise if you try to give it one. This way you could write placeholders for specs you know you want, but not allow you to put any code in them. Then there could be a command line option that allows you to report on yet-to-implement specs. Of course, if you insist on violating one of the most basic principles of BDD, you can write up your spec code and comment it out. The commented code would be in a logical place, but the tool would not be condoning the practice. Thoughts? David ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2006-10-30 02:57 Message: I submitted this. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6396&group_id=797 From noreply at rubyforge.org Mon Oct 30 19:22:50 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 Oct 2006 19:22:50 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6393 ] [PATCH] rspec_on_rails uses deprecated '@response' instead of the accessor Message-ID: <20061031002250.81305A970001@rubyforge.org> Patches item #6393, was opened at 2006-10-29 14:22 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6393&group_id=797 Category: None Group: None Status: Open >Resolution: Accepted Priority: 3 Submitted By: Wilson Bilkovich (wilson) >Assigned to: Aslak Hellesoy (aslak_hellesoy) Summary: [PATCH] rspec_on_rails uses deprecated '@response' instead of the accessor Initial Comment: Pretty much what the summary says. This fixes deprecation warnings when running controller specs against edge rails. ---------------------------------------------------------------------- >Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-30 19:22 Message: Fixed. Will be in 0.7 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6393&group_id=797 From noreply at rubyforge.org Mon Oct 30 19:22:59 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 Oct 2006 19:22:59 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6393 ] [PATCH] rspec_on_rails uses deprecated '@response' instead of the accessor Message-ID: <20061031002300.0A80BA970001@rubyforge.org> Patches item #6393, was opened at 2006-10-29 14:22 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6393&group_id=797 Category: None Group: None >Status: Closed Resolution: Accepted Priority: 3 Submitted By: Wilson Bilkovich (wilson) Assigned to: Aslak Hellesoy (aslak_hellesoy) Summary: [PATCH] rspec_on_rails uses deprecated '@response' instead of the accessor Initial Comment: Pretty much what the summary says. This fixes deprecation warnings when running controller specs against edge rails. ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-30 19:22 Message: Fixed. Will be in 0.7 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6393&group_id=797 From noreply at rubyforge.org Mon Oct 30 07:12:59 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 Oct 2006 07:12:59 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6396 ] Disabled Specifications and a Yellow build Message-ID: <20061030121259.941455241308@rubyforge.org> Feature Requests item #6396, was opened at 2006-10-30 07:51 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6396&group_id=797 Category: runner module Group: None Status: Open Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: Disabled Specifications and a Yellow build Initial Comment: Add a method that denotes a specification is disabled and causes a yellow build. For example: disable_specify "should support disabled specifications" do end This will be helpful in writing a spec before the feature is implemented. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-10-30 12:12 Message: FWIW - Irony of ironies, there is currently an abhorrently commented out spec in the trunk. And *I'm* the one who put it there. Even still, I'd rather do so and feel a little dirty about it than have the tool make me feel clean. Or even just a little yellow. Cheers, David ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-10-30 09:57 Message: Writing an entire specify block before a feature is implemented is not what BDD is about. It goes against the red/green/refactor cycle of TDD, which sits at the heart of BDD. For what it's worth, there is a similar feature in NUnit. I don't believe that I've ever seen it used to allow tests to be ignored in advance of implementation. I've only ever seen it used to ignore existing tests that had been passing and were now failing. Worse, I've seen this cause yellow to become the new green (i.e. an acceptable state for commits and sometimes even releases). Absolutely vile. That said, making decisions about behaviour in advance of implementation is very much aligned w/ BDD, even TDD. What would you think about something like this: implement "should support placeholders for yet to exist specs" This would not accept a block. In fact it would raise if you try to give it one. This way you could write placeholders for specs you know you want, but not allow you to put any code in them. Then there could be a command line option that allows you to report on yet-to-implement specs. Of course, if you insist on violating one of the most basic principles of BDD, you can write up your spec code and comment it out. The commented code would be in a logical place, but the tool would not be condoning the practice. Thoughts? David ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2006-10-30 07:57 Message: I submitted this. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6396&group_id=797 From noreply at rubyforge.org Mon Oct 30 20:30:40 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 Oct 2006 20:30:40 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6396 ] Disabled Specifications and a Yellow build Message-ID: <20061031013041.6BE3D524226B@rubyforge.org> Feature Requests item #6396, was opened at 2006-10-30 07:51 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6396&group_id=797 Category: runner module Group: None Status: Open Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: Disabled Specifications and a Yellow build Initial Comment: Add a method that denotes a specification is disabled and causes a yellow build. For example: disable_specify "should support disabled specifications" do end This will be helpful in writing a spec before the feature is implemented. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2006-10-31 01:30 Message: todo - I like that also. ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-31 00:18 Message: how about todo "something that needs doing" instead of implement "something that needs doing" because implement is really just a todo - isn't it? ---------------------------------------------------------------------- Comment By: Jay Levitt (jaylev) Date: 2006-10-30 13:33 Message: +1 for implement ---------------------------------------------------------------------- Comment By: Mike Vincent (agile) Date: 2006-10-30 13:07 Message: The suggested "implement" placeholder would be pretty cool. I have generally started fleshing out specs on rails based projects by flurrying through the model specs spewing out minimal specify statements for the limited things I know about them. Usually just throwing in violations as I'm flying through. Then I start running the specs and going through adding the contraints and going for green. It's a pretty noisy "todo" list when running the specs to find the placeholders. It'd be nice to have a more aesthetically pleasing "todo list" to work from. :) But I concur that being able to turn a real spec yellow probably isn't the behavior we're looking for. rake spec:implement or something that produced a spec:doc like format or something would be pretty nice. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-10-30 12:12 Message: FWIW - Irony of ironies, there is currently an abhorrently commented out spec in the trunk. And *I'm* the one who put it there. Even still, I'd rather do so and feel a little dirty about it than have the tool make me feel clean. Or even just a little yellow. Cheers, David ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-10-30 09:57 Message: Writing an entire specify block before a feature is implemented is not what BDD is about. It goes against the red/green/refactor cycle of TDD, which sits at the heart of BDD. For what it's worth, there is a similar feature in NUnit. I don't believe that I've ever seen it used to allow tests to be ignored in advance of implementation. I've only ever seen it used to ignore existing tests that had been passing and were now failing. Worse, I've seen this cause yellow to become the new green (i.e. an acceptable state for commits and sometimes even releases). Absolutely vile. That said, making decisions about behaviour in advance of implementation is very much aligned w/ BDD, even TDD. What would you think about something like this: implement "should support placeholders for yet to exist specs" This would not accept a block. In fact it would raise if you try to give it one. This way you could write placeholders for specs you know you want, but not allow you to put any code in them. Then there could be a command line option that allows you to report on yet-to-implement specs. Of course, if you insist on violating one of the most basic principles of BDD, you can write up your spec code and comment it out. The commented code would be in a logical place, but the tool would not be condoning the practice. Thoughts? David ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2006-10-30 07:57 Message: I submitted this. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6396&group_id=797 From noreply at rubyforge.org Mon Oct 30 20:20:34 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 Oct 2006 20:20:34 -0500 (EST) Subject: [rspec-devel] [ rspec-Bugs-6411 ] Can't run Rails specs with ruby Message-ID: <20061031012034.60FAF5242262@rubyforge.org> Bugs item #6411, was opened at 2006-10-30 20:20 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6411&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Aslak Hellesoy (aslak_hellesoy) Assigned to: Nobody (None) Summary: Can't run Rails specs with ruby Initial Comment: Standing in vendor/rspec_on_rails: ruby spec/models/person_spec.rb /Users/aslakhellesoy/scm/rspec/trunk/vendor/rspec_on_rails/config/../../../lib/spec/expectations/sugar.rb:13:in `call': undefined method `fixtures' for # (NoMethodError) from /Users/aslakhellesoy/scm/rspec/trunk/vendor/rspec_on_rails/config/../../../lib/spec/expectations/sugar.rb:13:in `_method_missing' from /Users/aslakhellesoy/scm/rspec/trunk/vendor/rspec_on_rails/config/../../../lib/spec/expectations/sugar.rb:9:in `method_missing' from /Users/aslakhellesoy/scm/rspec/trunk/vendor/rspec_on_rails/config/../../../lib/spec/runner/context_eval.rb:37:in `method_missing' from spec/models/person_spec.rb:4 from /Users/aslakhellesoy/scm/rspec/trunk/vendor/rspec_on_rails/config/../../../lib/spec/runner/context.rb:14:in `initialize' from /Users/aslakhellesoy/scm/rspec/trunk/vendor/rspec_on_rails/config/../vendor/plugins/rspec/lib/spec/rails/context_factory.rb:17:in `create' from /Users/aslakhellesoy/scm/rspec/trunk/vendor/rspec_on_rails/vendor/plugins/rspec/lib/extensions/kernel.rb:4:in `context' from spec/models/person_spec.rb:3 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6411&group_id=797 From noreply at rubyforge.org Mon Oct 30 20:46:08 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 Oct 2006 20:46:08 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6396 ] Disabled Specifications and a Yellow build Message-ID: <20061031014609.0BA845242262@rubyforge.org> Feature Requests item #6396, was opened at 2006-10-30 02:51 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6396&group_id=797 Category: runner module Group: None Status: Open Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: Disabled Specifications and a Yellow build Initial Comment: Add a method that denotes a specification is disabled and causes a yellow build. For example: disable_specify "should support disabled specifications" do end This will be helpful in writing a spec before the feature is implemented. ---------------------------------------------------------------------- >Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-30 20:46 Message: which leaves us to: # todo specify "something that needs doing" and then use my editor to find the todos. all good text editors have that built-in. why should we reimplement this in rspec? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-10-30 20:30 Message: todo - I like that also. ---------------------------------------------------------------------- Comment By: Aslak Hellesoy (aslak_hellesoy) Date: 2006-10-30 19:18 Message: how about todo "something that needs doing" instead of implement "something that needs doing" because implement is really just a todo - isn't it? ---------------------------------------------------------------------- Comment By: Jay Levitt (jaylev) Date: 2006-10-30 08:33 Message: +1 for implement ---------------------------------------------------------------------- Comment By: Mike Vincent (agile) Date: 2006-10-30 08:07 Message: The suggested "implement" placeholder would be pretty cool. I have generally started fleshing out specs on rails based projects by flurrying through the model specs spewing out minimal specify statements for the limited things I know about them. Usually just throwing in violations as I'm flying through. Then I start running the specs and going through adding the contraints and going for green. It's a pretty noisy "todo" list when running the specs to find the placeholders. It'd be nice to have a more aesthetically pleasing "todo list" to work from. :) But I concur that being able to turn a real spec yellow probably isn't the behavior we're looking for. rake spec:implement or something that produced a spec:doc like format or something would be pretty nice. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-10-30 07:12 Message: FWIW - Irony of ironies, there is currently an abhorrently commented out spec in the trunk. And *I'm* the one who put it there. Even still, I'd rather do so and feel a little dirty about it than have the tool make me feel clean. Or even just a little yellow. Cheers, David ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-10-30 04:57 Message: Writing an entire specify block before a feature is implemented is not what BDD is about. It goes against the red/green/refactor cycle of TDD, which sits at the heart of BDD. For what it's worth, there is a similar feature in NUnit. I don't believe that I've ever seen it used to allow tests to be ignored in advance of implementation. I've only ever seen it used to ignore existing tests that had been passing and were now failing. Worse, I've seen this cause yellow to become the new green (i.e. an acceptable state for commits and sometimes even releases). Absolutely vile. That said, making decisions about behaviour in advance of implementation is very much aligned w/ BDD, even TDD. What would you think about something like this: implement "should support placeholders for yet to exist specs" This would not accept a block. In fact it would raise if you try to give it one. This way you could write placeholders for specs you know you want, but not allow you to put any code in them. Then there could be a command line option that allows you to report on yet-to-implement specs. Of course, if you insist on violating one of the most basic principles of BDD, you can write up your spec code and comment it out. The commented code would be in a logical place, but the tool would not be condoning the practice. Thoughts? David ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2006-10-30 02:57 Message: I submitted this. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6396&group_id=797 From noreply at rubyforge.org Mon Oct 30 08:07:28 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 30 Oct 2006 08:07:28 -0500 (EST) Subject: [rspec-devel] [ rspec-Feature Requests-6396 ] Disabled Specifications and a Yellow build Message-ID: <20061030130728.66BC152415A3@rubyforge.org> Feature Requests item #6396, was opened at 2006-10-30 01:51 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6396&group_id=797 Category: runner module Group: None Status: Open Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: Disabled Specifications and a Yellow build Initial Comment: Add a method that denotes a specification is disabled and causes a yellow build. For example: disable_specify "should support disabled specifications" do end This will be helpful in writing a spec before the feature is implemented. ---------------------------------------------------------------------- Comment By: Mike Vincent (agile) Date: 2006-10-30 07:07 Message: The suggested "implement" placeholder would be pretty cool. I have generally started fleshing out specs on rails based projects by flurrying through the model specs spewing out minimal specify statements for the limited things I know about them. Usually just throwing in violations as I'm flying through. Then I start running the specs and going through adding the contraints and going for green. It's a pretty noisy "todo" list when running the specs to find the placeholders. It'd be nice to have a more aesthetically pleasing "todo list" to work from. :) But I concur that being able to turn a real spec yellow probably isn't the behavior we're looking for. rake spec:implement or something that produced a spec:doc like format or something would be pretty nice. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-10-30 06:12 Message: FWIW - Irony of ironies, there is currently an abhorrently commented out spec in the trunk. And *I'm* the one who put it there. Even still, I'd rather do so and feel a little dirty about it than have the tool make me feel clean. Or even just a little yellow. Cheers, David ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-10-30 03:57 Message: Writing an entire specify block before a feature is implemented is not what BDD is about. It goes against the red/green/refactor cycle of TDD, which sits at the heart of BDD. For what it's worth, there is a similar feature in NUnit. I don't believe that I've ever seen it used to allow tests to be ignored in advance of implementation. I've only ever seen it used to ignore existing tests that had been passing and were now failing. Worse, I've seen this cause yellow to become the new green (i.e. an acceptable state for commits and sometimes even releases). Absolutely vile. That said, making decisions about behaviour in advance of implementation is very much aligned w/ BDD, even TDD. What would you think about something like this: implement "should support placeholders for yet to exist specs" This would not accept a block. In fact it would raise if you try to give it one. This way you could write placeholders for specs you know you want, but not allow you to put any code in them. Then there could be a command line option that allows you to report on yet-to-implement specs. Of course, if you insist on violating one of the most basic principles of BDD, you can write up your spec code and comment it out. The commented code would be in a logical place, but the tool would not be condoning the practice. Thoughts? David ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2006-10-30 01:57 Message: I submitted this. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6396&group_id=797 From noreply at rubyforge.org Tue Oct 31 16:36:15 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 31 Oct 2006 16:36:15 -0500 (EST) Subject: [rspec-devel] [ rspec-Patches-6417 ] [PATCH] Support @object.some_method_should_be_changed_by {block} Message-ID: <20061031213615.A8FCD524230F@rubyforge.org> Patches item #6417, was opened at 2006-10-31 16:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Wilson Bilkovich (wilson) Assigned to: Nobody (None) Summary: [PATCH] Support @object.some_method_should_be_changed_by {block} Initial Comment: I was toying with how to implement the RSpec equivalent of "assert_difference" from test/unit. In case you haven't used it, it looks something like this: assert_difference some_object, :some_method { some code here } It calls some_object.some_method before and after the block, and fails if there is no difference. This patch implements something similarly generic: @some_object.some_method_should_be_changed_by {|obj| code here} ..and its inverse: @some_object.some_method_should_not_be_changed_by {|obj| code here} some_method is stripped from the beginning of the message, and passed forward for use inside the Should module. Has specs, and all other existing specs still pass. A real 'use case' example: User.count_should_be_changed_by do User.create :login => 'quentin', :email => 'blah at example.com'... end User.count will be different before and after, so this expectation will be met. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=6417&group_id=797