From noreply at rubyforge.org Sat Sep 1 04:11:37 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 1 Sep 2007 04:11:37 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-13567 ] patch to allow stubs to yield consecutive values Message-ID: <20070901081137.5E19AA97002E@rubyforge.org> Patches item #13567, was opened at 2007-09-01 09:11 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13567&group_id=797 Category: mock module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Rupert Voelcker (rupert) Assigned to: Nobody (None) Summary: patch to allow stubs to yield consecutive values Initial Comment: This addresses the issue raised in [#12841], complete with passing specs and docs update. It uses the 'chained and_yield' syntax so allowing arity flexibility. I've entered it as a new patch as for some reason I can't upload a file to the original. Cheers Rupert ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13567&group_id=797 From noreply at rubyforge.org Sat Sep 1 09:21:00 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 1 Sep 2007 09:21:00 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-13567 ] patch to allow stubs to yield consecutive values Message-ID: <20070901132100.979035240B3C@rubyforge.org> Patches item #13567, was opened at 2007-09-01 08:11 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13567&group_id=797 Category: mock module Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Rupert Voelcker (rupert) >Assigned to: David Chelimsky (dchelimsky) Summary: patch to allow stubs to yield consecutive values Initial Comment: This addresses the issue raised in [#12841], complete with passing specs and docs update. It uses the 'chained and_yield' syntax so allowing arity flexibility. I've entered it as a new patch as for some reason I can't upload a file to the original. Cheers Rupert ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-01 13:21 Message: Applied to r2485. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13567&group_id=797 From noreply at rubyforge.org Sat Sep 1 09:25:41 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 1 Sep 2007 09:25:41 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-12841 ] Allow stubs to yield consecutive values Message-ID: <20070901132541.CCC8B5240ABF@rubyforge.org> Patches item #12841, was opened at 2007-08-06 06:13 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12841&group_id=797 Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Pat Maddox (pergesu) Assigned to: Nobody (None) Summary: Allow stubs to yield consecutive values Initial Comment: Scott Taylor asked, I have a mock of an instance of a class which descends from Array: class ArrayDescendent < Array; end #... in the specs... @descendent = mock ArrayDescendent How would I stub out ArrayDescendent#each, which is inherited from Array, to return multiple values successively? I could use and_yield, but that is raising an arity error (the anonymous function/ block should expect only *one value at a time, but and_yield is yielding both values once). Should I be using a lambda expression here? This patch provides the #and_yield_consecutively method for mocks and stubs. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-01 13:25 Message: Fixed with patch 13567: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13567&group_id=797 The approach in that patch is to say and_yield multiple times rather than adding a new method. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-08-31 22:19 Message: Our plan is to deprecate the mocking framework, but I don't think we're totally there yet. And so I leave it to you as to whether you want to submit the patch. If you do and it's fine, I'll gladly add it. ---------------------------------------------------------------------- Comment By: Rupert Voelcker (rupert) Date: 2007-08-31 22:16 Message: seeing as I've now worked out how to rspec rspec, I could submit (rather then knock up) a spec'd patch for this that uses the chained and_yield syntax. ....but afore I do is the mocking framework still being updated, and is this wanted as I guess there's no point if the answer to either of these is no (and I should try and get something into mocha instead). Cheers Rupert ---------------------------------------------------------------------- Comment By: Rupert Voelcker (rupert) Date: 2007-08-17 10:47 Message: ah - cool! ---------------------------------------------------------------------- Comment By: Rupert Voelcker (rupert) Date: 2007-08-17 10:45 Message: Aslak - the arity issue (to me) is if you have: obj.should_receive(:msg).and_yield([a,b],[c,d]) and you assume that this is a consecutive yield, you can use it to spec yilelder1 in the following class: class MyClass def yielder1 yield([1,2]) yield([3,4]) end def yielder2 yield([1,2], [3,4]) end end However, you couldn't then spec yielder2. This problem is potentially there for and_return too (I think), as as far as I know you can return multiple values (although being quite new to ruby I've not used this feature yet so don't actually know). Not sure what the differences are that Dave had in mind, but to me the difference is that and_return (as currently handled in rspec) can only return one value per message call. and_yield can return multiple values many times per message call. P.S. still can't see where to submit a file - there's just a list of attached files and download links at the bottom and a list of changes :( Not that this is particularly imporatant! ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-08-17 10:23 Message: Doh, I just understood the arity problem. I'm an idiot. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-08-17 10:19 Message: Rupert: There is a form at the bottom of this page for patches. Just remember to check the checkbox. I still haven't heard a good argument for doing this differently from #and_return. What arity problems do you mean? I don't like the chained #and_yield form - it's overly verbose and it introduces a new idiom for something that should be similar to the cousin #and_return. Dave, you suggested that #and_yield is a different beast than #and_return. How so? ---------------------------------------------------------------------- Comment By: Rupert Voelcker (rupert) Date: 2007-08-16 21:56 Message: no idea how to add the patch file, so it's at: http://pastie.textmate.org/88416 ---------------------------------------------------------------------- Comment By: Rupert Voelcker (rupert) Date: 2007-08-16 21:51 Message: I like the look of the chained and_yield's myself, as it's pretty clear what's happening and avoids arity probs. An alternative is to have something along the lines of obj.should_receive(:msg).and_yield(....stuff to yield....).with_arity(2) then if the number of args is a multiple of the arity then yield consecutively the multiple number of times. If the number of args isn't a multiple of the arity then raise an arity error. Does this seem like a good idea, or would it be confusing? Anyway, I've made up a patch for handling the chained yields (I presume it'll allow me to upload after I hit submit - not used a tracker before) No tests as I can't work out how to run the tests on rspec and if the arity approach is better the patch is junk anyway. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-08-13 00:05 Message: IMO: obj.should_receive(:msg).and_yield([a,b],[c,d]) obj.msg # => [a,b] obj.msg # => [c,d] obj.msg # => [c,d] # When/if we reach the end, just yield the last one. Wouldn't that work? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-08-12 23:27 Message: So how would that work with arity > 1? obj.should_receive(:msg).and_yield([a,b],[c,d]) Does that mean: - yield two arrays on the first call - yield one array each for the first two calls - yield two args each for the first two calls This problem doesn't apply to and_return. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-08-12 23:13 Message: This should be done in the same way as and_return(*consecutive_values) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-08-12 22:48 Message: Right now you can do this to get consecutive yield values: obj.should_receive(:msg).and_yield(value1) obj.should_receive(:msg).and_yield(value2) The problem with putting all the values to be yielded in one statement is that rspec would have no way of knowing definitively what is a single array argument vs an array of consecutive arguments. Conceivably, we could so something like: obj.should_receive(:msg) .and_yield(value1) .and_yield(value2) .and_yield(value3) .and_yield(value4) But is that really that much of an advantage? ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2007-08-06 07:06 Message: I'm not sure why I thought all? was the proper method to use. Just collect the return values and pass them back. ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2007-08-06 06:40 Message: I realized I should probably explain why this is necessary. Yielded values represent the input values to an anonymous function (block). Since a function can take more than 1 argument, there's no way of knowing whether multiple values are supposed to be passed in at once or returned consecutively. This gives us both options, without any magic that might introduce arity errors. ---------------------------------------------------------------------- Comment By: Pat Maddox (pergesu) Date: 2007-08-06 06:31 Message: A little bit of multi-arity love. it "should support yielding consecutive values to a *-arity block" do yielded_values = [] @obj.stub!(:method_that_yields).and_yield_consecutively(["biscuits", "and"], ["gravy", "is"], ["good", "eatin"]) @obj.method_that_yields {|val1, val2| yielded_values << "#{val1} #{val2}" } yielded_values.should == [ "biscuits and", "gravy is", "good eatin"] @obj.rspec_verify end Each group of yielded values is in an array. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12841&group_id=797 From noreply at rubyforge.org Sat Sep 1 09:33:22 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 1 Sep 2007 09:33:22 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-13143 ] ActionView::Helpers::RecordIdentificationHelper should be included if present Message-ID: <20070901133322.913FA5240CA2@rubyforge.org> Patches item #13143, was opened at 2007-08-16 21:45 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13143&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Jay Levitt (jaylev) Assigned to: Nobody (None) Summary: ActionView::Helpers::RecordIdentificationHelper should be included if present Initial Comment: as summary. This was added in edge r6633. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-01 13:33 Message: Applied to r2486. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13143&group_id=797 From noreply at rubyforge.org Sat Sep 1 09:58:10 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 1 Sep 2007 09:58:10 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-12895 ] mocks with inline stubs Message-ID: <20070901135810.6A2C85240CA2@rubyforge.org> Feature Requests item #12895, was opened at 2007-08-08 00:51 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12895&group_id=797 Category: None Group: None >Status: Closed Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) Assigned to: Nobody (None) Summary: mocks with inline stubs Initial Comment: Oftentimes I find myself with a setup like this: @mock = mock Object Object.stub!(:new).and_return @mock @mock.stub!(:method_one).and_return "foo" @mock.stub!(:method_two).and_return "bar" After several mock objects + their stubs in one setup/before block, this can get quite hard to read. This code could be abstracted into a helper method, but I find that generally does not help the readability of the situation. Would the following solve the problem: obj = mock Object do |o| Object.stub!(:new).and_return o o.stub!(:method_one).and_return "foo" o.stub!(:method_two).and_return "bar" end or with an implicit receiver: obj = mock Object do stub!(:method_one).and_return "foo" stub!(:method_two).and_return "bar" end I think this would go along way to making before/setup blocks easier to read, if, for no other reason, then the convention of pretty prettying. WDYT? ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-01 13:58 Message: I'm going to reject this one. You can either do this: Object.stub!(:new).and_return( stub("object", :method_one => "foo", :method_two => "bar ) ) or try RR. ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-08-08 05:25 Message: Yes RR does support that type of syntax. I've been meaning to make a blog post that has a tutorial. Lets say you want to stub User.new. In RR, you can say: # This mocks each instance of User with the expectations that method_one and method_two will be called once and return "foo" and "bar". mock.instance_of(User) do |o| o.method_one {"foo"} o.method_two {"bar"} end or alternatively: # This allows the real call to User.new and intercepts the return value stub.probe(User).new do |user| mock(user).method_one {"foo"} mock(user).method_two {"bar"} user end Of course, literally stubbing Object.new will cause a stack error on any of Ruby's mock frameworks. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-08-08 03:56 Message: There's already a shorthand for this: Object.stub!(:new).and_return( stub( "object", :method_one => "foo", :method_two => "bar ) ) To be honest, I find the example you gave at the beginning much easier to grok what's going on than the alternatives you suggest. Although, perhaps the first one would be a bit cleaner like this: Object.stub!(:new).and_return(mock(Object) do |o| o.stub!(:method_one).and_return "foo" o.stub!(:method_two).and_return "bar" end) You might be interested in Brian Takita's new framework called RR. I'm pretty sure it let's you this: obj = mock(Object) do |o| o.method_one { "foo" } o.method_two { "bar" } end Brian - if you read this please confirm or deny. I'm inclined to close this, but I'll leave it open for others to comment. Comments? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12895&group_id=797 From noreply at rubyforge.org Sat Sep 1 10:03:49 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 1 Sep 2007 10:03:49 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-13574 ] cleaner syntax for consecutive return values Message-ID: <20070901140349.78DB95240CD5@rubyforge.org> Feature Requests item #13574, was opened at 2007-09-01 14:03 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13574&group_id=797 Category: mock module Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: cleaner syntax for consecutive return values Initial Comment: We just added this to trunk for multiple yields: @mock.should_receive(:message).once. and_yield('wha', 'zup'). and_yield('not', 'down'). and_yield(14, 65) We should do something similar for consecutive returns: @mock.should_receive(:message). and_return('wha', 'zup'). and_return('not', 'down'). and_return(14, 65) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13574&group_id=797 From mailing_lists at railsnewbie.com Sat Sep 1 13:26:14 2007 From: mailing_lists at railsnewbie.com (Scott Taylor) Date: Sat, 1 Sep 2007 13:26:14 -0400 Subject: [rspec-devel] Congrats & stubbing methods with specific args question Message-ID: Congratulations on the 1.0.9 release! This release, I think, is worth at least a major version number (if not 2.0)- with rbehave, the internals of rspec completely refactored, the textmate bundle with lots of new features, enhancements to the mocking framework, etc. So thanks for all the hard work - especially Dan North, Brian Takita - and the usual suspects: David & Aslak. Just one thing on the changeset that I saw: * You can now stub!(:msg).with(specific args) Does this mean that a stub with specific args will only be stubbed in those cases, but in others it will act as if it weren't? This may be one of the best new features of rspec. Thanks, all, for your help, support, and hard work, Scott From dchelimsky at gmail.com Sat Sep 1 13:33:09 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 1 Sep 2007 12:33:09 -0500 Subject: [rspec-devel] Congrats & stubbing methods with specific args question In-Reply-To: References: Message-ID: <57c63afe0709011033q24f72d6co25e752ddd1252fa8@mail.gmail.com> On 9/1/07, Scott Taylor wrote: > > Congratulations on the 1.0.9 release! Huh? Release? News to me. > This release, I think, is > worth at least a major version number (if not 2.0)- with rbehave, the > internals of rspec completely refactored, the textmate bundle with > lots of new features, enhancements to the mocking framework, etc. So > thanks for all the hard work - especially Dan North, Brian Takita - > and the usual suspects: David & Aslak. We'll probably make it 1.1. There's still a lot of unification of the runners to happen before we get anywhere near a 2.0. > > Just one thing on the changeset that I saw: > > * You can now stub!(:msg).with(specific args) > > Does this mean that a stub with specific args will only be stubbed > in those cases, but in others it will act as if it weren't? Not quite. It means that you can set up different stub return values for different argument values, but it does NOT mean that the call will be passed on to the object if those values are not sent in. Once you stub or mock a method on a real object, that method is owned by the mock framework. > This may > be one of the best new features of rspec. > > Thanks, all, for your help, support, and hard work, > > Scott > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From noreply at rubyforge.org Sat Sep 1 13:45:50 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 1 Sep 2007 13:45:50 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-13579 ] NoMethodError not raised for missing helper methods Message-ID: <20070901174550.4D4095240DAA@rubyforge.org> Bugs item #13579, was opened at 2007-09-01 18:45 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13579&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Rupert Voelcker (rupert) Assigned to: Nobody (None) Summary: NoMethodError not raised for missing helper methods Initial Comment: If in a helper spec you spec a method that doesn't exist in the helper a NoMethodError isn't raised. This means that a spec like: describe PeopleHelper do it "should return 'garbage'" do non_existant_helper_method.should == 'garbage' end end passes when the non_existant_helper_method doesn't exist in the helper. I've enclosed a diff file containing a failing spec. Having a wee look with the debugger, it goes through the end of method_missing of rails_behaviour.rb where it gets super'd up to the method_missing in prototype_helper.rb which creates a new JavaScrptProxy -this doesn't seem quite right. Not having any idea how this part of things works I'm afraid I can't suggest anything at the moment so I'm hoping some bright spark will know straightaway what's wrong. Cheers Rupert ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13579&group_id=797 From mailing_lists at railsnewbie.com Sat Sep 1 14:16:35 2007 From: mailing_lists at railsnewbie.com (Scott Taylor) Date: Sat, 1 Sep 2007 14:16:35 -0400 Subject: [rspec-devel] Congrats & stubbing methods with specific args question In-Reply-To: <57c63afe0709011033q24f72d6co25e752ddd1252fa8@mail.gmail.com> References: <57c63afe0709011033q24f72d6co25e752ddd1252fa8@mail.gmail.com> Message-ID: On Sep 1, 2007, at 1:33 PM, David Chelimsky wrote: > On 9/1/07, Scott Taylor wrote: >> >> Congratulations on the 1.0.9 release! > > Huh? Release? News to me. Ah - I was confused when I looked at the changeset. I saw this: == Version 1.0.9 Textmate Bundle users - this release adds a new RSpec bundle that highlights describe, it, before and after and provides navigation to descriptions and examples (rather than classes and methods). When you first install this, it is going to try to hijack all of your .rb files. All you need to do is open a .rb file that does not end with 'spec.rb' and change the bundle selection from RSpec to Ruby. TextMate will do the right thing from then on. * Applied [#11254] RSpec syntax coloring and function pop-up integration in TextMate (Patch from Wincent Colaiuta) ... I figured you guys had made a new release. I guess you put up that header even when the gem hasn't been released yet. Scott From mailing_lists at railsnewbie.com Sat Sep 1 14:18:35 2007 From: mailing_lists at railsnewbie.com (Scott Taylor) Date: Sat, 1 Sep 2007 14:18:35 -0400 Subject: [rspec-devel] Congrats & stubbing methods with specific args question In-Reply-To: <57c63afe0709011033q24f72d6co25e752ddd1252fa8@mail.gmail.com> References: <57c63afe0709011033q24f72d6co25e752ddd1252fa8@mail.gmail.com> Message-ID: <1B2C2521-48F7-45AC-ACAC-7153125620B1@railsnewbie.com> On Sep 1, 2007, at 1:33 PM, David Chelimsky wrote: > On 9/1/07, Scott Taylor wrote: >> >> Congratulations on the 1.0.9 release! > > Huh? Release? News to me. > >> This release, I think, is >> worth at least a major version number (if not 2.0)- with rbehave, the >> internals of rspec completely refactored, the textmate bundle with >> lots of new features, enhancements to the mocking framework, etc. So >> thanks for all the hard work - especially Dan North, Brian Takita - >> and the usual suspects: David & Aslak. > > We'll probably make it 1.1. There's still a lot of unification of the > runners to happen before we get anywhere near a 2.0. > >> >> Just one thing on the changeset that I saw: >> >> * You can now stub!(:msg).with(specific args) >> >> Does this mean that a stub with specific args will only be stubbed >> in those cases, but in others it will act as if it weren't? > > Not quite. It means that you can set up different stub return values > for different argument values, but it does NOT mean that the call will > be passed on to the object if those values are not sent in. Once you > stub or mock a method on a real object, that method is owned by the > mock framework. So say you have the following obj.stub!(:a_method).with(1) and the object receives: obj.a_method(2) Is there something like a MockExpectationError which is raised? Scott From dan at tastapod.com Sat Sep 1 18:40:18 2007 From: dan at tastapod.com (Dan North) Date: Sat, 01 Sep 2007 23:40:18 +0100 Subject: [rspec-devel] Congrats & stubbing methods with specific args question In-Reply-To: References: <57c63afe0709011033q24f72d6co25e752ddd1252fa8@mail.gmail.com> Message-ID: <46D9EA52.3090902@tastapod.com> Hi Scott. > Ah - I was confused when I looked at the changeset. I saw this: > > == Version 1.0.9 > That's the "holding area" for changes that are going to be in the next release (nominally 1.0.9, but as David says, it might be 1.1.0). You'll often see the next release number in trunk a way ahead of the actual release going out. It's useful for being able to build a rake package with a gem with the next release number so you can gem install it and play around. David is being (understandably) conservative about announcing a 1.0.9 (or 1.1) release. A lot of stuff has changed so I expect he wants to be fairly confident before releasing a new gem that will impact a lot of users. Either that or he's just being a slacker ;) > I figured you guys had made a new release. I guess you put up that > header even when the gem hasn't been released yet. > Yep, exactly. Actually it's pretty helpful to be able to look in the change log at what /else/ has changed, to make sure I haven't broken anything I didn't know about. Cheers, Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070901/31ab6659/attachment.html From noreply at rubyforge.org Sat Sep 1 19:11:48 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 1 Sep 2007 19:11:48 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-13554 ] Add & amp; quot; And& amp; quot; so you can say Given... And... When... Then... And... Message-ID: <20070901231148.DA7B65240E1B@rubyforge.org> Feature Requests item #13554, was opened at 2007-08-31 14:12 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13554&group_id=797 Category: Story Runner Group: None >Status: Closed Priority: 3 Submitted By: Dan North (tastapod) Assigned to: Dan North (tastapod) >Summary: Add &amp;quot;And&amp;quot; so you can say Given... And... When... Then... And... Initial Comment: When you write a scenario, the natural English is: Given something And something else When this happens And this happens Then this should be true And so should this There should be an And() method in World that supports this construct. ---------------------------------------------------------------------- >Comment By: Dan North (tastapod) Date: 2007-09-02 00:11 Message: Updated PlainTextDocumenter to print And for multiple givens, events and outcomes. Committed as r2489. The decision has to be in the documenter because a step may be used as the first Given in one scenario, and as an additional Given (and therefore documented as "And") in another. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-08-31 15:50 Message: No apologies, please. It's too early for that :) ---------------------------------------------------------------------- Comment By: Dan North (tastapod) Date: 2007-08-31 15:49 Message: Whoops. Didn't think of that! Also, apologies for not putting a revision number with the previous comment. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-08-31 15:31 Message: Reopening this - I've got this: Given "user is already registered as", "foo", "test" do |login, password| @user = User.create!(:login => login, :password => password, :password_confirmation => password, :email => 'a at b.com') @user.activate @user.save! end When "user logs in with", "foo", "test", :follow_redirect => true do |login, password, opts| post "/sessions", :login => login, :password => password follow_redirect! if opts[:follow_redirect] end Then "user should see", 'polls/index' do |template_path| response.should render_template(template_path) end And "user should see link to", "My Profile" do |link| response.should have_tag("a", link) end .... but it gets reported like this: Given user is already registered as foo,test When user logs in with foo,test,follow_redirecttrue Then user should see polls/index Then user should see link to My Profile That second Then is an And in the code and should reported as such, no? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-08-31 15:27 Message: Hey Dan - we're in the habit of noting the revision number when a ticket gets closed. Done. r2483 ---------------------------------------------------------------------- Comment By: Dan North (tastapod) Date: 2007-08-31 14:18 Message: Done. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13554&group_id=797 From dchelimsky at gmail.com Sun Sep 2 00:08:45 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 1 Sep 2007 23:08:45 -0500 Subject: [rspec-devel] Congrats & stubbing methods with specific args question In-Reply-To: <1B2C2521-48F7-45AC-ACAC-7153125620B1@railsnewbie.com> References: <57c63afe0709011033q24f72d6co25e752ddd1252fa8@mail.gmail.com> <1B2C2521-48F7-45AC-ACAC-7153125620B1@railsnewbie.com> Message-ID: <57c63afe0709012108q71ac2389o8724af74bc60b7@mail.gmail.com> On 9/1/07, Scott Taylor wrote: > > On Sep 1, 2007, at 1:33 PM, David Chelimsky wrote: > > > On 9/1/07, Scott Taylor wrote: > >> > >> Congratulations on the 1.0.9 release! > > > > Huh? Release? News to me. > > > >> This release, I think, is > >> worth at least a major version number (if not 2.0)- with rbehave, the > >> internals of rspec completely refactored, the textmate bundle with > >> lots of new features, enhancements to the mocking framework, etc. So > >> thanks for all the hard work - especially Dan North, Brian Takita - > >> and the usual suspects: David & Aslak. > > > > We'll probably make it 1.1. There's still a lot of unification of the > > runners to happen before we get anywhere near a 2.0. > > > >> > >> Just one thing on the changeset that I saw: > >> > >> * You can now stub!(:msg).with(specific args) > >> > >> Does this mean that a stub with specific args will only be stubbed > >> in those cases, but in others it will act as if it weren't? > > > > Not quite. It means that you can set up different stub return values > > for different argument values, but it does NOT mean that the call will > > be passed on to the object if those values are not sent in. Once you > > stub or mock a method on a real object, that method is owned by the > > mock framework. > > So say you have the following > > obj.stub!(:a_method).with(1) > > and the object receives: > > obj.a_method(2) > > Is there something like a MockExpectationError which is raised? As of now, no. This is a problem use case that we should figure out how it should behave. It's a stub, so you don't expect it to complain. But how should obj behave when it does receive :a_method with 2? Thoughts? > > Scott > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dchelimsky at gmail.com Sun Sep 2 04:31:23 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 2 Sep 2007 03:31:23 -0500 Subject: [rspec-devel] experimental rails story adapter in trunk In-Reply-To: <48933.147.114.226.182.1188491290.squirrel@www.tastapod.com> References: <57c63afe0708292147k58ab553ag68b064c3fa8d1351@mail.gmail.com> <48933.147.114.226.182.1188491290.squirrel@www.tastapod.com> Message-ID: <57c63afe0709020131p6534523eu25fdc0110a565422@mail.gmail.com> On 8/30/07, dan at tastapod.com wrote: > > For those of you interested in getting a jump on learning about and > > using the new Story Runner in a Rails app, I've added an experimental > > Rails-Story adapter to trunk. > > > > You can see how to use it here: > > > > http://pastie.caboo.se/92320 > > > > This is PURELY EXPERIMENTAL, however it actually works and will likely > > not change much in the way that it does work. > > > > Happy hacking! > > > > David > > I tidied it up a bit - there were some parameters that weren't being used > as parameters. It's now at http://pastie.caboo.se/92472. > > Also, I'm wondering (out loud) whether you can do this: > > When "creating a new person with no name" do > When "creating a new person named", nil > end I'm not a big fan of this nesting w/ When, but if it used a verb of some sort I might like it - When "creating a new person with no name" do Exec "creating a new person named", nil Do "creating a new person named", nil Run "creating a new person named", nil Invoke "creating a new person named", nil Call "creating a new person named", nil end Not sure about any of those, but you get the idea. > > It _feels_ like it should work. Can't see why it wouldn't. Better yet, you > could have a method: > > def create_person(name) > post "/people/create", :person => {:name => name} > end > > at the Story or Scenario level and call it from both Whens. That seems the better choice to me. > > Cheers, > Dan > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From lists-rspec at shopwatch.org Sun Sep 2 16:23:56 2007 From: lists-rspec at shopwatch.org (Jay Levitt) Date: Sun, 02 Sep 2007 16:23:56 -0400 Subject: [rspec-devel] [ rspec-Feature Requests-13532 ] /lib specs should get base EvalContext In-Reply-To: <57c63afe0708302046y3354fd46q3c39744543433566@mail.gmail.com> References: <20070830220901.B34805240C70@rubyforge.org> <46D7710B.3050906@jay.fm> <57c63afe0708302046y3354fd46q3c39744543433566@mail.gmail.com> Message-ID: <46DB1BDC.1050007@shopwatch.org> On 8/30/2007 11:46 PM, David Chelimsky wrote: > On 8/30/07, Jay Levitt wrote: >>> I set this up a bit differently - there was already a RailsBehaviour which is the base for ModelBehaviour, ViewBehaviour, ControllerBehaviour and HelperBehaviour. I made it so that is the default for ANY directory outside models, views, controllers, and helpers. It has mock_model, add_stubs and general fixtures support. >>> >>> Right now, ModelBehaviour simply derives from RailsBehaviour but doesn't add anything additional. It seems like it wants to be deprecated, but that's a topic for another thread. >> That sounds great. I don't think ModelBehaviour needs deprecation; it >> seems obvious that someone will need to create it in the future, so >> might as well keep it for symmetry. rspec_on_rails is early days even >> compared to rspec! >> >> That said, I noticed FunctionalBehaviour still kicking around; isn't >> that deprecated? > > Nope. That's the base class for ControllerBehaviour, ViewBehaviour and > HelperBehaviour. Sigh. I think Eclipse's search doesn't like me sometimes. Jay From noreply at rubyforge.org Sun Sep 2 19:12:29 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 2 Sep 2007 19:12:29 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-13607 ] README for running stories Message-ID: <20070902231230.210795240E77@rubyforge.org> Patches item #13607, was opened at 2007-09-02 16:12 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13607&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Ian Dees (undees) Assigned to: Nobody (None) Summary: README for running stories Initial Comment: I'm attaching a simple README to go in the examples/story directory and explain the basics of running stories (both the provided game-of-life ones and the reader's own). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13607&group_id=797 From noreply at rubyforge.org Sun Sep 2 19:13:19 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 2 Sep 2007 19:13:19 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-13607 ] README for running stories Message-ID: <20070902231319.CA73C5240D64@rubyforge.org> Patches item #13607, was opened at 2007-09-02 16:12 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13607&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Ian Dees (undees) Assigned to: Nobody (None) Summary: README for running stories Initial Comment: I'm attaching a simple README to go in the examples/story directory and explain the basics of running stories (both the provided game-of-life ones and the reader's own). ---------------------------------------------------------------------- >Comment By: Ian Dees (undees) Date: 2007-09-02 16:13 Message: It's a patch against r2492, btw. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13607&group_id=797 From dchelimsky at gmail.com Mon Sep 3 01:53:42 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 3 Sep 2007 00:53:42 -0500 Subject: [rspec-devel] blog post on story runner Message-ID: <57c63afe0709022253x15a3b07ev19168560a1636990@mail.gmail.com> Here's an excellent blog post on Story Runner, which will be part of the next release and is undergoing active development in trunk: http://evang.eli.st/blog/2007/9/1/user-stories-with-rspec-s-story-runner From noreply at rubyforge.org Mon Sep 3 07:23:20 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 3 Sep 2007 07:23:20 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-13616 ] [CODE included] Testing RJS helper methods Message-ID: <20070903112321.0F2995240999@rubyforge.org> Feature Requests item #13616, was opened at 2007-09-03 13:23 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13616&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Simon Nicholls (simon_nicholls) Assigned to: Nobody (None) Summary: [CODE included] Testing RJS helper methods Initial Comment: Hi, I like to test my RJS helper methods using RSpec. These are the helper methods that have a page object implicitly provided for their use. As an example, for: update_page {|page| page.notify("kitten")} in the controller With the helper being: def notify(message) page[:notice].replace_html message end I can do: describe AjaxHelper, "notify" do it "should update notice area" do rjs_for.notify("kitten").should have_rjs(:chained_replace_html, "notice") end end To do this, I include a Helper module, but it could be in core using code similar to the following (all in dsl/behaviour/helper.rb). In ExampleMethods module, alongside eval_erb: def rjs_for HelperRJSPageProxy.new(self) end Then where other classes are defined (e.g. HelperEvalContextController): class HelperRJSPageProxy def initialize(context) @context = context end def method_missing(method, *arguments) block = Proc.new { |page| @lines = []; page.send(method, *arguments) } @context.response.body = ActionView::Helpers::PrototypeHelper::JavaScriptGenerator.new(@context, &block).to_s @context.response end end I checked out the RSpec trunk, thinking to make a patch, but failed to get far with understanding RSpec's own spec layout and speccing the spec. Hope you find the code useful! It's been handy to be able to test RJS helpers, and it would be great to have in core. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13616&group_id=797 From noreply at rubyforge.org Tue Sep 4 06:33:34 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 4 Sep 2007 06:33:34 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-13645 ] Support for alternative expectations Message-ID: <20070904103335.46CCF5240A69@rubyforge.org> Feature Requests item #13645, was opened at 2007-09-04 12:33 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13645&group_id=797 Category: mock module Group: None Status: Open Priority: 3 Submitted By: Rodrigo Alvarez (papipo) Assigned to: Nobody (None) Summary: Support for alternative expectations Initial Comment: I would like to be able to do something like: @model.should_receive(:save).and_return(true).or_receive(:save!).and_raise(ActiveRecord::RecordNotSaved) At the moment I must stub both methods, and that does the work, but that way I'm not specifying what is supposed to happen. This allows more verbosity. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13645&group_id=797 From noreply at rubyforge.org Tue Sep 4 19:29:54 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 4 Sep 2007 19:29:54 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-13661 ] View Specs - Allow controller to be defined (default to ApplicationController) Message-ID: <20070904232955.0343D5240D2E@rubyforge.org> Feature Requests item #13661, was opened at 2007-09-04 16:29 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13661&group_id=797 Category: rails plugin Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: View Specs - Allow controller to be defined (default to ApplicationController) Initial Comment: This will give the view access to helper_methods defined in the controller. e.g. describe "foo/show.erb" do controller_name "foo" it "should have method defined from foo controller" do template.foobar.should == "I'm defined in FooController" end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13661&group_id=797 From michael.s.klishin.lists at gmail.com Wed Sep 5 19:42:13 2007 From: michael.s.klishin.lists at gmail.com (Michael Klishin) Date: Thu, 06 Sep 2007 03:42:13 +0400 Subject: [rspec-devel] Trac instead of Rubyforge tracker? Message-ID: <46DF3ED5.7040109@gmail.com> Guys, I'm trying to follow RSpec development but constantly find out that I have no time to read all emails from dev list and read commit logs / source changes. Maybe it makes sense to set up Trac? Beside being a bit better at tracking requests and bug reports it has Timeline and Roadmap that save huge amount of time compared to SVN logs and source digging. WDYT? -- MK From noreply at rubyforge.org Wed Sep 5 20:14:43 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 5 Sep 2007 20:14:43 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-13699 ] In HelperSpec with_routing is not working Message-ID: <20070906001443.0B8CCA97000B@rubyforge.org> Bugs item #13699, was opened at 2007-09-06 12:14 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13699&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Shane Mingins (smingins) Assigned to: Nobody (None) Summary: In HelperSpec with_routing is not working Initial Comment: In version 1.05 we have specs with examples like: describe SomeHelper do it "should work with_routing" do with_routing do |set| set.draw do |map| map.resources :thoughts end thought_path(:id => 1).should == "/thoughts/1" end end end and this works and passes fine. In version 1.08 this does not work and throws an exception similar to the named routes problem that was fixed by installing the routes to the ExampleMethods modules. That fix does not fix this problem and I am wondering as to how 1.05 has access to the routeset as opposed to trunk adding: ActionController::Routing::Routes.named_routes.install(self) The exception message (from my spec called CommentsHelperSpec is: You have a nil object when you didn't expect it! You might have expected an instance of Array. The error occurred while evaluating nil.<< /Users/smingins/Work/comments_new/config/../vendor/rails/actionpack/lib/action_view/helpers/prototype_helper.rb:538:in `<<' /Users/smingins/Work/comments_new/config/../vendor/rails/actionpack/lib/action_view/helpers/prototype_helper.rb:695:in `initialize' /Users/smingins/Work/comments_new/config/../vendor/rails/actionpack/lib/action_view/helpers/prototype_helper.rb:616:in `new' /Users/smingins/Work/comments_new/config/../vendor/rails/actionpack/lib/action_view/helpers/prototype_helper.rb:616:in `method_missing' /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/matchers.rb:159:in `method_missing' ./spec/helper/comments_helper_spec.rb:27: /Users/smingins/Work/comments_new/config/../vendor/rails/actionpack/lib/action_controller/test_process.rb:487:in `with_routing' ./spec/helper/comments_helper_spec.rb:22: /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/dsl/example.rb:81:in `instance_eval' /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/dsl/example.rb:81:in `run_example' /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/dsl/example.rb:26:in `run' /opt/local/lib/ruby/1.8/timeout.rb:48:in `timeout' /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/dsl/example.rb:24:in `run' /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:81:in `run' /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:75:in `each' /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:75:in `run' /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:58:in `run_behaviours' /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:57:in `each' /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:57:in `run_behaviours' /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:21:in `run' /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/runner/command_line.rb:17:in `run' ./script/spec:4: Please let me know if I have provided enough information. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13699&group_id=797 From mlangenberg at gmail.com Thu Sep 6 03:34:39 2007 From: mlangenberg at gmail.com (Matthijs Langenberg) Date: Thu, 6 Sep 2007 09:34:39 +0200 Subject: [rspec-devel] Trac instead of Rubyforge tracker? In-Reply-To: <46DF3ED5.7040109@gmail.com> References: <46DF3ED5.7040109@gmail.com> Message-ID: <27c0ac6d0709060034r2cf89c06uef55ee466bbcb1d2@mail.gmail.com> I agree with you that the Rubyforge tracker isn't the ideal tracker, but it's integrated in Rubyforge, so that's a plus. Setting up Trac might cost a great deal of time, and will it really benefit the development process? If we're talking about Trac, we should also put lighthouse into the consideration. On 9/6/07, Michael Klishin wrote: > > Guys, > > I'm trying to follow RSpec development but constantly find out that I > have no time to read all emails from dev list and read commit logs / > source changes. > > Maybe it makes sense to set up Trac? Beside being a bit better at > tracking requests and bug reports it has Timeline and Roadmap that save > huge amount of time compared to SVN logs and source digging. > > WDYT? > > -- > MK > _______________________________________________ > 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/20070906/757e42dd/attachment.html From noreply at rubyforge.org Thu Sep 6 04:16:26 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 6 Sep 2007 04:16:26 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-13708 ] Revision 2482 killed custom assertions in spec:ui Message-ID: <20070906081627.66BB75240EF1@rubyforge.org> Bugs item #13708, was opened at 2007-09-06 10:16 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13708&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Marcus Ahnve (mahnve) Assigned to: Nobody (None) Summary: Revision 2482 killed custom assertions in spec:ui Initial Comment: Rev 2482 did something that takes our custom expectations for Selenium using spec:ui out of the call chain - they are no longer called at all. In revision 2481 this works. I've tried running the Watir examples, which custom expectations we basically copied, and they seem broken too. I am trying to locate what in that rev that causes this to happen, but I have so far been unsuccessful. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13708&group_id=797 From noreply at rubyforge.org Thu Sep 6 04:39:04 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 6 Sep 2007 04:39:04 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-13708 ] Revision 2482 killed custom assertions in spec:ui Message-ID: <20070906083905.15ACD5240953@rubyforge.org> Bugs item #13708, was opened at 2007-09-06 10:16 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13708&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Marcus Ahnve (mahnve) Assigned to: Nobody (None) Summary: Revision 2482 killed custom assertions in spec:ui Initial Comment: Rev 2482 did something that takes our custom expectations for Selenium using spec:ui out of the call chain - they are no longer called at all. In revision 2481 this works. I've tried running the Watir examples, which custom expectations we basically copied, and they seem broken too. I am trying to locate what in that rev that causes this to happen, but I have so far been unsuccessful. ---------------------------------------------------------------------- >Comment By: Marcus Ahnve (mahnve) Date: 2007-09-06 10:39 Message: I found the line causing this to happen: In rspec_on_rails/lib/spec/rails/dsl/behaviour/rails_example.rb, the line Spec::DSL::BehaviourFactory.add_behaviour_class(:default, self) does something that reoverrides our custom expectations. The problem seems to be that the rspec_on_rails expectations by the call above are defined after our custom definitions. It therefore only affects our own "have_tag" etc, which have a expectation with the same name in RSpec On Rails. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13708&group_id=797 From noreply at rubyforge.org Thu Sep 6 06:55:27 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 6 Sep 2007 06:55:27 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-13713 ] form helper method 'select' can not be called when calling custom helper methods from specs Message-ID: <20070906105527.B9E895240953@rubyforge.org> Bugs item #13713, was opened at 2007-09-06 13:55 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13713&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Juha Suuraho (juhazi) Assigned to: Nobody (None) Summary: form helper method 'select' can not be called when calling custom helper methods from specs Initial Comment: Method select from ActionView::Helpers::FormOptionsHelper cannot be called from helper specs. helper code: def return_a_select select(:test_object, :test_method, ["1",1]) end spec code: it "should return a select input tag" do return_a_select.should_not be_nil end result: ArgumentError in 'CompaniesHelper should return a select input tag' wrong number of arguments (3 for 1) suggested reason: in /vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/helper.rb: +++++++++++++++++++++++++++++++++++++++ module ExampleMethods ..... include ActionView::Helpers::FormHelper include ActionView::Helpers::FormOptionsHelper include ActionView::Helpers::FormTagHelper ..... include ActionView::Helpers::PrototypeHelper include ActionView::Helpers::PrototypeHelper::JavaScriptGenerator::GeneratorMethods include ActionView::Helpers::ScriptaculousHelper ++++++++++++++++++++++++++++++++++++++++ as you can see FormOptionsHelper is included before PrototypeHelper::JavaScriptGenerator::GeneratorMethods, which in my opinion results in the select helper method from latter to overwrite the former. I'm not sure how this could be fixed if the latter helper module is by default included in all helpers. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13713&group_id=797 From noreply at rubyforge.org Thu Sep 6 07:35:47 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 6 Sep 2007 07:35:47 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-13713 ] form helper method 'select' can not be called when calling custom helper methods from specs Message-ID: <20070906113547.4E0E15240AC1@rubyforge.org> Bugs item #13713, was opened at 2007-09-06 10:55 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13713&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Juha Suuraho (juhazi) Assigned to: Nobody (None) Summary: form helper method 'select' can not be called when calling custom helper methods from specs Initial Comment: Method select from ActionView::Helpers::FormOptionsHelper cannot be called from helper specs. helper code: def return_a_select select(:test_object, :test_method, ["1",1]) end spec code: it "should return a select input tag" do return_a_select.should_not be_nil end result: ArgumentError in 'CompaniesHelper should return a select input tag' wrong number of arguments (3 for 1) suggested reason: in /vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/helper.rb: +++++++++++++++++++++++++++++++++++++++ module ExampleMethods ..... include ActionView::Helpers::FormHelper include ActionView::Helpers::FormOptionsHelper include ActionView::Helpers::FormTagHelper ..... include ActionView::Helpers::PrototypeHelper include ActionView::Helpers::PrototypeHelper::JavaScriptGenerator::GeneratorMethods include ActionView::Helpers::ScriptaculousHelper ++++++++++++++++++++++++++++++++++++++++ as you can see FormOptionsHelper is included before PrototypeHelper::JavaScriptGenerator::GeneratorMethods, which in my opinion results in the select helper method from latter to overwrite the former. I'm not sure how this could be fixed if the latter helper module is by default included in all helpers. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-06 11:35 Message: The javascript helpers are a recent addition and seem to be causing trouble. Maybe we should yank them. If you need them in a spec, you can always include them yourself. Thoughts? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13713&group_id=797 From noreply at rubyforge.org Thu Sep 6 07:43:54 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 6 Sep 2007 07:43:54 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11726 ] Rspec on Rails does not use Active Record's fixture optimization Message-ID: <20070906114354.808B65240953@rubyforge.org> Bugs item #11726, was opened at 2007-06-20 22:43 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11726&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Rspec on Rails does not use Active Record's fixture optimization Initial Comment: Active Record fixtures are "cached" in a Hash based on the class. Since Rspec uses anonymous classes, there are no cache hits. See fixtures.rb in ActiveRecord line 537. If we can figure out how to utilize there cached fixtures, specs that use fixtures will be considerably faster. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-06 11:43 Message: Brian - in light of the current refactoring to concrete classes, I think this can be closed - yes? ---------------------------------------------------------------------- Comment By: Brian Takita (btakita) Date: 2007-06-20 23:02 Message: The other benefit to fixing this is using "all" of the fixtures for every example would pretty much be free, as long as transactional fixtures are used. This means we don't need to worry about which fixtures need to be loaded for the example. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11726&group_id=797 From noreply at rubyforge.org Thu Sep 6 08:47:53 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 6 Sep 2007 08:47:53 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-13713 ] form helper method 'select' can not be called when calling custom helper methods from specs Message-ID: <20070906124754.060D85240AAE@rubyforge.org> Bugs item #13713, was opened at 2007-09-06 13:55 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13713&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Juha Suuraho (juhazi) Assigned to: Nobody (None) Summary: form helper method 'select' can not be called when calling custom helper methods from specs Initial Comment: Method select from ActionView::Helpers::FormOptionsHelper cannot be called from helper specs. helper code: def return_a_select select(:test_object, :test_method, ["1",1]) end spec code: it "should return a select input tag" do return_a_select.should_not be_nil end result: ArgumentError in 'CompaniesHelper should return a select input tag' wrong number of arguments (3 for 1) suggested reason: in /vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/helper.rb: +++++++++++++++++++++++++++++++++++++++ module ExampleMethods ..... include ActionView::Helpers::FormHelper include ActionView::Helpers::FormOptionsHelper include ActionView::Helpers::FormTagHelper ..... include ActionView::Helpers::PrototypeHelper include ActionView::Helpers::PrototypeHelper::JavaScriptGenerator::GeneratorMethods include ActionView::Helpers::ScriptaculousHelper ++++++++++++++++++++++++++++++++++++++++ as you can see FormOptionsHelper is included before PrototypeHelper::JavaScriptGenerator::GeneratorMethods, which in my opinion results in the select helper method from latter to overwrite the former. I'm not sure how this could be fixed if the latter helper module is by default included in all helpers. ---------------------------------------------------------------------- >Comment By: Juha Suuraho (juhazi) Date: 2007-09-06 15:47 Message: After more research, atleast this particular helper(ActionView::Helpers::PrototypeHelper::JavaScriptGenerator::GeneratorMethods) are not meant to be included in the default helper scope, but to be used inside a javascript generating block, like: update_page do |page| page.select('some_id') end atleast this module should be removed from the include list. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-09-06 14:35 Message: The javascript helpers are a recent addition and seem to be causing trouble. Maybe we should yank them. If you need them in a spec, you can always include them yourself. Thoughts? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13713&group_id=797 From noreply at rubyforge.org Thu Sep 6 09:15:49 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 6 Sep 2007 09:15:49 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-13713 ] form helper method 'select' can not be called when calling custom helper methods from specs Message-ID: <20070906131549.9BCE15240AE8@rubyforge.org> Bugs item #13713, was opened at 2007-09-06 10:55 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13713&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Juha Suuraho (juhazi) >Assigned to: David Chelimsky (dchelimsky) Summary: form helper method 'select' can not be called when calling custom helper methods from specs Initial Comment: Method select from ActionView::Helpers::FormOptionsHelper cannot be called from helper specs. helper code: def return_a_select select(:test_object, :test_method, ["1",1]) end spec code: it "should return a select input tag" do return_a_select.should_not be_nil end result: ArgumentError in 'CompaniesHelper should return a select input tag' wrong number of arguments (3 for 1) suggested reason: in /vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/helper.rb: +++++++++++++++++++++++++++++++++++++++ module ExampleMethods ..... include ActionView::Helpers::FormHelper include ActionView::Helpers::FormOptionsHelper include ActionView::Helpers::FormTagHelper ..... include ActionView::Helpers::PrototypeHelper include ActionView::Helpers::PrototypeHelper::JavaScriptGenerator::GeneratorMethods include ActionView::Helpers::ScriptaculousHelper ++++++++++++++++++++++++++++++++++++++++ as you can see FormOptionsHelper is included before PrototypeHelper::JavaScriptGenerator::GeneratorMethods, which in my opinion results in the select helper method from latter to overwrite the former. I'm not sure how this could be fixed if the latter helper module is by default included in all helpers. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-06 13:15 Message: I believe that you are correct. Looking at the way Rails includes these helpers in ActionView::Base, it does not get included automatically. I've removed ActionView::Helpers::PrototypeHelper::JavaScriptGenerator: :GeneratorMethods. Fixed in r2527 ---------------------------------------------------------------------- Comment By: Juha Suuraho (juhazi) Date: 2007-09-06 12:47 Message: After more research, atleast this particular helper(ActionView::Helpers::PrototypeHelper::JavaScriptGenerator::GeneratorMethods) are not meant to be included in the default helper scope, but to be used inside a javascript generating block, like: update_page do |page| page.select('some_id') end atleast this module should be removed from the include list. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-09-06 11:35 Message: The javascript helpers are a recent addition and seem to be causing trouble. Maybe we should yank them. If you need them in a spec, you can always include them yourself. Thoughts? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13713&group_id=797 From noreply at rubyforge.org Thu Sep 6 09:17:14 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 6 Sep 2007 09:17:14 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-13699 ] In HelperSpec with_routing is not working Message-ID: <20070906131714.3CB9F5240B01@rubyforge.org> Bugs item #13699, was opened at 2007-09-06 00:14 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13699&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Shane Mingins (smingins) Assigned to: Nobody (None) Summary: In HelperSpec with_routing is not working Initial Comment: In version 1.05 we have specs with examples like: describe SomeHelper do it "should work with_routing" do with_routing do |set| set.draw do |map| map.resources :thoughts end thought_path(:id => 1).should == "/thoughts/1" end end end and this works and passes fine. In version 1.08 this does not work and throws an exception similar to the named routes problem that was fixed by installing the routes to the ExampleMethods modules. That fix does not fix this problem and I am wondering as to how 1.05 has access to the routeset as opposed to trunk adding: ActionController::Routing::Routes.named_routes.install(self) The exception message (from my spec called CommentsHelperSpec is: You have a nil object when you didn't expect it! You might have expected an instance of Array. The error occurred while evaluating nil.<< /Users/smingins/Work/comments_new/config/../vendor/rails/actionpack/lib/action_view/helpers/prototype_helper.rb:538:in `<<' /Users/smingins/Work/comments_new/config/../vendor/rails/actionpack/lib/action_view/helpers/prototype_helper.rb:695:in `initialize' /Users/smingins/Work/comments_new/config/../vendor/rails/actionpack/lib/action_view/helpers/prototype_helper.rb:616:in `new' /Users/smingins/Work/comments_new/config/../vendor/rails/actionpack/lib/action_view/helpers/prototype_helper.rb:616:in `method_missing' /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/matchers.rb:159:in `method_missing' ./spec/helper/comments_helper_spec.rb:27: /Users/smingins/Work/comments_new/config/../vendor/rails/actionpack/lib/action_controller/test_process.rb:487:in `with_routing' ./spec/helper/comments_helper_spec.rb:22: /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/dsl/example.rb:81:in `instance_eval' /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/dsl/example.rb:81:in `run_example' /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/dsl/example.rb:26:in `run' /opt/local/lib/ruby/1.8/timeout.rb:48:in `timeout' /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/dsl/example.rb:24:in `run' /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:81:in `run' /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:75:in `each' /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:75:in `run' /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:58:in `run_behaviours' /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:57:in `each' /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:57:in `run_behaviours' /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:21:in `run' /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/runner/command_line.rb:17:in `run' ./script/spec:4: Please let me know if I have provided enough information. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-06 13:17 Message: Shane - we removed to fix http://rubyforge.org/tracker/index.php?func=detail&aid=13713&group_id=797&atid=3149. Can you check and see if that resolves this problem as well? Thanks ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13699&group_id=797 From noreply at rubyforge.org Thu Sep 6 09:23:48 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 6 Sep 2007 09:23:48 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-13579 ] NoMethodError not raised for missing helper methods Message-ID: <20070906132348.2ACEB5240B01@rubyforge.org> Bugs item #13579, was opened at 2007-09-01 17:45 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13579&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Rupert Voelcker (rupert) Assigned to: Nobody (None) Summary: NoMethodError not raised for missing helper methods Initial Comment: If in a helper spec you spec a method that doesn't exist in the helper a NoMethodError isn't raised. This means that a spec like: describe PeopleHelper do it "should return 'garbage'" do non_existant_helper_method.should == 'garbage' end end passes when the non_existant_helper_method doesn't exist in the helper. I've enclosed a diff file containing a failing spec. Having a wee look with the debugger, it goes through the end of method_missing of rails_behaviour.rb where it gets super'd up to the method_missing in prototype_helper.rb which creates a new JavaScrptProxy -this doesn't seem quite right. Not having any idea how this part of things works I'm afraid I can't suggest anything at the moment so I'm hoping some bright spark will know straightaway what's wrong. Cheers Rupert ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-06 13:23 Message: This was fixed with [13713] (http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13713&group_id=797). I've added your example (slightly tweaked - it raises a NameError, not a NoMethodError) to the plugin specs (not the example app specs). Thanks! Fixed in r2528 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13579&group_id=797 From noreply at rubyforge.org Thu Sep 6 14:35:07 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 6 Sep 2007 14:35:07 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-13717 ] typo in docs Message-ID: <20070906183507.D6D6E5240BF1@rubyforge.org> Patches item #13717, was opened at 2007-09-06 22:35 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13717&group_id=797 Category: mock module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Yury Kotlyarov (yury_kotlyarov) Assigned to: Nobody (None) Summary: typo in docs Initial Comment: typo "subsquently" in a couple of files ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13717&group_id=797 From noreply at rubyforge.org Thu Sep 6 20:25:32 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 6 Sep 2007 20:25:32 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-13699 ] In HelperSpec with_routing is not working Message-ID: <20070907002533.8AF475240F00@rubyforge.org> Bugs item #13699, was opened at 2007-09-06 12:14 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13699&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Shane Mingins (smingins) Assigned to: Nobody (None) Summary: In HelperSpec with_routing is not working Initial Comment: In version 1.05 we have specs with examples like: describe SomeHelper do it "should work with_routing" do with_routing do |set| set.draw do |map| map.resources :thoughts end thought_path(:id => 1).should == "/thoughts/1" end end end and this works and passes fine. In version 1.08 this does not work and throws an exception similar to the named routes problem that was fixed by installing the routes to the ExampleMethods modules. That fix does not fix this problem and I am wondering as to how 1.05 has access to the routeset as opposed to trunk adding: ActionController::Routing::Routes.named_routes.install(self) The exception message (from my spec called CommentsHelperSpec is: You have a nil object when you didn't expect it! You might have expected an instance of Array. The error occurred while evaluating nil.<< /Users/smingins/Work/comments_new/config/../vendor/rails/actionpack/lib/action_view/helpers/prototype_helper.rb:538:in `<<' /Users/smingins/Work/comments_new/config/../vendor/rails/actionpack/lib/action_view/helpers/prototype_helper.rb:695:in `initialize' /Users/smingins/Work/comments_new/config/../vendor/rails/actionpack/lib/action_view/helpers/prototype_helper.rb:616:in `new' /Users/smingins/Work/comments_new/config/../vendor/rails/actionpack/lib/action_view/helpers/prototype_helper.rb:616:in `method_missing' /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/matchers.rb:159:in `method_missing' ./spec/helper/comments_helper_spec.rb:27: /Users/smingins/Work/comments_new/config/../vendor/rails/actionpack/lib/action_controller/test_process.rb:487:in `with_routing' ./spec/helper/comments_helper_spec.rb:22: /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/dsl/example.rb:81:in `instance_eval' /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/dsl/example.rb:81:in `run_example' /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/dsl/example.rb:26:in `run' /opt/local/lib/ruby/1.8/timeout.rb:48:in `timeout' /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/dsl/example.rb:24:in `run' /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:81:in `run' /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:75:in `each' /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:75:in `run' /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:58:in `run_behaviours' /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:57:in `each' /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:57:in `run_behaviours' /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:21:in `run' /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/runner/command_line.rb:17:in `run' ./script/spec:4: Please let me know if I have provided enough information. ---------------------------------------------------------------------- >Comment By: Shane Mingins (smingins) Date: 2007-09-07 12:25 Message: Hi David Yes that solves everything. So in Spec::Rails::DSL::HelperBehaviourHelpers::ExampleMethods I removed: include ActionView::Helpers::PrototypeHelper::JavaScriptGenerator::GeneratorMethods And I no longer need to do: ActionController::Routing::Routes.named_routes.install(self) Thanks Shane ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-09-07 01:17 Message: Shane - we removed to fix http://rubyforge.org/tracker/index.php?func=detail&aid=13713&group_id=797&atid=3149. Can you check and see if that resolves this problem as well? Thanks ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13699&group_id=797 From noreply at rubyforge.org Thu Sep 6 21:03:31 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 6 Sep 2007 21:03:31 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-13699 ] In HelperSpec with_routing is not working Message-ID: <20070907010331.257DE5240F0B@rubyforge.org> Bugs item #13699, was opened at 2007-09-06 00:14 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13699&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Shane Mingins (smingins) Assigned to: Nobody (None) Summary: In HelperSpec with_routing is not working Initial Comment: In version 1.05 we have specs with examples like: describe SomeHelper do it "should work with_routing" do with_routing do |set| set.draw do |map| map.resources :thoughts end thought_path(:id => 1).should == "/thoughts/1" end end end and this works and passes fine. In version 1.08 this does not work and throws an exception similar to the named routes problem that was fixed by installing the routes to the ExampleMethods modules. That fix does not fix this problem and I am wondering as to how 1.05 has access to the routeset as opposed to trunk adding: ActionController::Routing::Routes.named_routes.install(self) The exception message (from my spec called CommentsHelperSpec is: You have a nil object when you didn't expect it! You might have expected an instance of Array. The error occurred while evaluating nil.<< /Users/smingins/Work/comments_new/config/../vendor/rails/actionpack/lib/action_view/helpers/prototype_helper.rb:538:in `<<' /Users/smingins/Work/comments_new/config/../vendor/rails/actionpack/lib/action_view/helpers/prototype_helper.rb:695:in `initialize' /Users/smingins/Work/comments_new/config/../vendor/rails/actionpack/lib/action_view/helpers/prototype_helper.rb:616:in `new' /Users/smingins/Work/comments_new/config/../vendor/rails/actionpack/lib/action_view/helpers/prototype_helper.rb:616:in `method_missing' /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/matchers.rb:159:in `method_missing' ./spec/helper/comments_helper_spec.rb:27: /Users/smingins/Work/comments_new/config/../vendor/rails/actionpack/lib/action_controller/test_process.rb:487:in `with_routing' ./spec/helper/comments_helper_spec.rb:22: /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/dsl/example.rb:81:in `instance_eval' /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/dsl/example.rb:81:in `run_example' /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/dsl/example.rb:26:in `run' /opt/local/lib/ruby/1.8/timeout.rb:48:in `timeout' /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/dsl/example.rb:24:in `run' /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:81:in `run' /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:75:in `each' /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/dsl/behaviour.rb:75:in `run' /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:58:in `run_behaviours' /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:57:in `each' /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:57:in `run_behaviours' /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:21:in `run' /Users/smingins/Work/comments_new/vendor/plugins/rspec/lib/spec/runner/command_line.rb:17:in `run' ./script/spec:4: Please let me know if I have provided enough information. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-07 01:03 Message: Cool. I'm going to close this then. Cheers! ---------------------------------------------------------------------- Comment By: Shane Mingins (smingins) Date: 2007-09-07 00:25 Message: Hi David Yes that solves everything. So in Spec::Rails::DSL::HelperBehaviourHelpers::ExampleMethods I removed: include ActionView::Helpers::PrototypeHelper::JavaScriptGenerator::GeneratorMethods And I no longer need to do: ActionController::Routing::Routes.named_routes.install(self) Thanks Shane ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-09-06 13:17 Message: Shane - we removed to fix http://rubyforge.org/tracker/index.php?func=detail&aid=13713&group_id=797&atid=3149. Can you check and see if that resolves this problem as well? Thanks ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13699&group_id=797 From noreply at rubyforge.org Fri Sep 7 04:05:19 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 7 Sep 2007 04:05:19 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-13741 ] Helper specs oddities, compared to controller and other specs Message-ID: <20070907080519.6123B5240F28@rubyforge.org> Bugs item #13741, was opened at 2007-09-07 10:05 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13741&group_id=797 Category: mock module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Johan S?rensen (johansorensen) Assigned to: Nobody (None) Summary: Helper specs oddities, compared to controller and other specs Initial Comment: I've always found it odd that helpers called directly in the it() block, and not through an instance of some sort, eg typing it "should do stuff" do helper_method.should == "output" end and even worse it "should do stuff" do mock(:helper_method).and_return("thingies") #.. end eg its not obvious at first sight exactly what you're mocking/expecting on, and its very inconsistant to general (non-rails) specs and controller/model specifications, where operate on some object. Why not mix the helper into a dummy Helper object instead? So we can do: it "should do stuff" do helper.mock(:helper_method).and_return("thingies") helper.other_method.should == "thingies are good" end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13741&group_id=797 From noreply at rubyforge.org Fri Sep 7 05:40:02 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 7 Sep 2007 05:40:02 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-13741 ] Helper specs oddities, compared to controller and other specs Message-ID: <20070907094002.290FC5240952@rubyforge.org> Bugs item #13741, was opened at 2007-09-07 08:05 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13741&group_id=797 Category: mock module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Johan S?rensen (johansorensen) Assigned to: Nobody (None) Summary: Helper specs oddities, compared to controller and other specs Initial Comment: I've always found it odd that helpers called directly in the it() block, and not through an instance of some sort, eg typing it "should do stuff" do helper_method.should == "output" end and even worse it "should do stuff" do mock(:helper_method).and_return("thingies") #.. end eg its not obvious at first sight exactly what you're mocking/expecting on, and its very inconsistant to general (non-rails) specs and controller/model specifications, where operate on some object. Why not mix the helper into a dummy Helper object instead? So we can do: it "should do stuff" do helper.mock(:helper_method).and_return("thingies") helper.other_method.should == "thingies are good" end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-07 09:40 Message: That's a great idea, but a year late. We could offer up a helper object as an alternative, but I wouldn't want to break any existing helper specs in the process. The only problem there is that it becomes confusing when you're allowed to write things in both ways and then someone else comes in contact with the specs and sees it "should do stuff" do helper.mock(:helper_method).and_return("thingies") other_method.should == "thingies are good" end WDYT? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13741&group_id=797 From noreply at rubyforge.org Fri Sep 7 05:50:49 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 7 Sep 2007 05:50:49 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-13741 ] Helper specs oddities, compared to controller and other specs Message-ID: <20070907095049.EA6B15240844@rubyforge.org> Bugs item #13741, was opened at 2007-09-07 10:05 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13741&group_id=797 Category: mock module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Johan S?rensen (johansorensen) Assigned to: Nobody (None) Summary: Helper specs oddities, compared to controller and other specs Initial Comment: I've always found it odd that helpers called directly in the it() block, and not through an instance of some sort, eg typing it "should do stuff" do helper_method.should == "output" end and even worse it "should do stuff" do mock(:helper_method).and_return("thingies") #.. end eg its not obvious at first sight exactly what you're mocking/expecting on, and its very inconsistant to general (non-rails) specs and controller/model specifications, where operate on some object. Why not mix the helper into a dummy Helper object instead? So we can do: it "should do stuff" do helper.mock(:helper_method).and_return("thingies") helper.other_method.should == "thingies are good" end ---------------------------------------------------------------------- >Comment By: Johan S?rensen (johansorensen) Date: 2007-09-07 11:50 Message: I think (or guess we'd have to as you say) supporting both, and recommending the helper.foo approach where it's possible (docs, examples), and then deprecating/removing the existing approach whenever it's appropriate (1.5/2.0) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-09-07 11:40 Message: That's a great idea, but a year late. We could offer up a helper object as an alternative, but I wouldn't want to break any existing helper specs in the process. The only problem there is that it becomes confusing when you're allowed to write things in both ways and then someone else comes in contact with the specs and sees it "should do stuff" do helper.mock(:helper_method).and_return("thingies") other_method.should == "thingies are good" end WDYT? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13741&group_id=797 From noreply at rubyforge.org Fri Sep 7 06:05:46 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 7 Sep 2007 06:05:46 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11526 ] rspec fails to dynamically bind DelegateClass methods Message-ID: <20070907100546.39E725240ACF@rubyforge.org> Bugs item #11526, was opened at 2007-06-12 15:55 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11526&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: John Prince (jtprince) Assigned to: Nobody (None) Summary: rspec fails to dynamically bind DelegateClass methods Initial Comment: DelegateClass fails with rspec when methods are defined in the the delegating class. I'm using a delegate class right now and I'm having to write spaghetti code to get things to work properly. Here's code that demonstrates the problem: --- require 'delegate' gem 'rspec' # Version 1.0.5 ############################################################ # CONTROL EXAMPLE: Works FINE. ############################################################ class InheritedClass < Array def large? self.size >= 5 end end describe InheritedClass, "normal inheriting class is OK" do it 'works just fine' do myclass = InheritedClass.new([1,2,3,4,5,6]) myclass.should be_large end end ############################################################ # rspec should work on DelegateClasses. Not sure how... ############################################################ class DelegateKlass < DelegateClass(Array) def initialize(array) @internal_array = array super(@internal_array) end def large? @internal_array.size >= 5 end end =begin # will work if this code is available. class Array def large? self.size >= 5 end end =end describe DelegateKlass, "delegate class fails" do it 'does not work on methods defined within the delegating class' do myclass = DelegateKlass.new([1,2,3,4,5,6]) myclass.should be_large end end --- ############################################# # OUTPUT: ############################################# .F 1) NoMethodError in 'DelegateKlass delegate class fails does not work on delegate class' undefined method `large?' for [1, 2, 3, 4, 5, 6]:Array ./spec_delegate.rb:53: Finished in 0.007365 seconds 2 examples, 1 failure ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-07 10:05 Message: Well, I've learned one interesting thing about this. If you define the DelegateKlass first and then require 'spec' (or gem 'rspec') it works fine. So there is some odd relationship between what require 'spec' does to Object or the main object and what DelegateClass does. Don't know more than that yet. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11526&group_id=797 From noreply at rubyforge.org Fri Sep 7 15:12:47 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 7 Sep 2007 15:12:47 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-13759 ] rails_rspec overwrites test mappings added in .autotest Message-ID: <20070907191247.DB0B0A97000E@rubyforge.org> Bugs item #13759, was opened at 2007-09-07 19:12 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13759&group_id=797 Category: Autotest Group: v1.0 (example) Status: Open Resolution: None Priority: 3 Submitted By: Geoffrey Wiseman (diathesis) Assigned to: Nobody (None) Summary: rails_rspec overwrites test mappings added in .autotest Initial Comment: If you add any any test mappings to .autotest, rails_rspec seems to trample these; that means any added directories (e.g. spec/acceptance) have to be added in rails_rspec, currently. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13759&group_id=797 From noreply at rubyforge.org Fri Sep 7 15:15:14 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 7 Sep 2007 15:15:14 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-13760 ] False Positives on eql?() Message-ID: <20070907191516.047605240C37@rubyforge.org> Bugs item #13760, was opened at 2007-09-07 19:15 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13760&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Geoffrey Wiseman (diathesis) Assigned to: Nobody (None) Summary: False Positives on eql?() Initial Comment: I accidentally typed: ob.should eql?(something) This passed incorrectly. It seems to be that I've essentially compared the 'something' value to the behavior object, and generated a false; by way of example, this also passes: ob.should false Both of these are presumably dangerous false positives, particularly the former that's one keystroke away from the valid approach, and in keeping with eql? elsewhere, so it's an easy mistake to make. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13760&group_id=797 From aslak.hellesoy at gmail.com Fri Sep 7 18:15:26 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sat, 8 Sep 2007 00:15:26 +0200 Subject: [rspec-devel] Trac instead of Rubyforge tracker? In-Reply-To: <46DF3ED5.7040109@gmail.com> References: <46DF3ED5.7040109@gmail.com> Message-ID: <8d961d900709071515q415c0e71n17046c3fedb3efea@mail.gmail.com> On 9/6/07, Michael Klishin wrote: > Guys, > > I'm trying to follow RSpec development but constantly find out that I > have no time to read all emails from dev list and read commit logs / > source changes. > > Maybe it makes sense to set up Trac? Beside being a bit better at > tracking requests and bug reports it has Timeline and Roadmap that save > huge amount of time compared to SVN logs and source digging. > > WDYT? > Trac needs a local svn, and we can't set it up at Rubyforge. We'd have to move everything away from rubyforge. Aslak > -- > MK > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From noreply at rubyforge.org Fri Sep 7 18:26:47 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 7 Sep 2007 18:26:47 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-13760 ] False Positives on eql?() Message-ID: <20070907222647.9954D5240D08@rubyforge.org> Bugs item #13760, was opened at 2007-09-07 15:15 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13760&group_id=797 Category: expectation module Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Geoffrey Wiseman (diathesis) >Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: False Positives on eql?() Initial Comment: I accidentally typed: ob.should eql?(something) This passed incorrectly. It seems to be that I've essentially compared the 'something' value to the behavior object, and generated a false; by way of example, this also passes: ob.should false Both of these are presumably dangerous false positives, particularly the former that's one keystroke away from the valid approach, and in keeping with eql? elsewhere, so it's an easy mistake to make. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-09-07 18:26 Message: I don't understand what you mean, nor is there any complete code here I can execute to reproduce what you say is a bug. Please submit some more complete code on the mailing list to make sure what you're talking about is a bug or not. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13760&group_id=797 From noreply at rubyforge.org Fri Sep 7 18:32:53 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 7 Sep 2007 18:32:53 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-13760 ] False Positives on eql?() Message-ID: <20070907223253.84F745240D0B@rubyforge.org> Bugs item #13760, was opened at 2007-09-07 15:15 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13760&group_id=797 Category: expectation module Group: None >Status: Open >Resolution: Accepted Priority: 3 Submitted By: Geoffrey Wiseman (diathesis) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: False Positives on eql?() Initial Comment: I accidentally typed: ob.should eql?(something) This passed incorrectly. It seems to be that I've essentially compared the 'something' value to the behavior object, and generated a false; by way of example, this also passes: ob.should false Both of these are presumably dangerous false positives, particularly the former that's one keystroke away from the valid approach, and in keeping with eql? elsewhere, so it's an easy mistake to make. ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-09-07 18:32 Message: Sorry, my bad - I just saw that you actually had posted on the list first, and having read the mail I understand what you mean. How would you like RSpec to behave in the situation you describe? Can you describe that with a (failing) spec? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-09-07 18:26 Message: I don't understand what you mean, nor is there any complete code here I can execute to reproduce what you say is a bug. Please submit some more complete code on the mailing list to make sure what you're talking about is a bug or not. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13760&group_id=797 From noreply at rubyforge.org Fri Sep 7 20:15:20 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 7 Sep 2007 20:15:20 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-13760 ] False Positives on eql?() Message-ID: <20070908001520.9653D5240D0B@rubyforge.org> Bugs item #13760, was opened at 2007-09-07 19:15 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13760&group_id=797 Category: expectation module Group: None Status: Open Resolution: Accepted Priority: 3 Submitted By: Geoffrey Wiseman (diathesis) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: False Positives on eql?() Initial Comment: I accidentally typed: ob.should eql?(something) This passed incorrectly. It seems to be that I've essentially compared the 'something' value to the behavior object, and generated a false; by way of example, this also passes: ob.should false Both of these are presumably dangerous false positives, particularly the former that's one keystroke away from the valid approach, and in keeping with eql? elsewhere, so it's an easy mistake to make. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-08 00:15 Message: should and should_not both take a matcher (an object that responds to matches?). If no matcher is passed, it handles operators (should == expected). In the case of handling operators, nothing gets passed to should. My thinking is that if anything besides a matcher is passed to should, it should raise an InvalidArgument error. WDYT? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-09-07 22:32 Message: Sorry, my bad - I just saw that you actually had posted on the list first, and having read the mail I understand what you mean. How would you like RSpec to behave in the situation you describe? Can you describe that with a (failing) spec? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-09-07 22:26 Message: I don't understand what you mean, nor is there any complete code here I can execute to reproduce what you say is a bug. Please submit some more complete code on the mailing list to make sure what you're talking about is a bug or not. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13760&group_id=797 From noreply at rubyforge.org Fri Sep 7 23:03:02 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 7 Sep 2007 23:03:02 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-13760 ] False Positives on eql?() Message-ID: <20070908030302.C47995240D40@rubyforge.org> Bugs item #13760, was opened at 2007-09-07 19:15 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13760&group_id=797 Category: expectation module Group: None Status: Open Resolution: Accepted Priority: 3 Submitted By: Geoffrey Wiseman (diathesis) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: False Positives on eql?() Initial Comment: I accidentally typed: ob.should eql?(something) This passed incorrectly. It seems to be that I've essentially compared the 'something' value to the behavior object, and generated a false; by way of example, this also passes: ob.should false Both of these are presumably dangerous false positives, particularly the former that's one keystroke away from the valid approach, and in keeping with eql? elsewhere, so it's an easy mistake to make. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-08 03:03 Message: I just committed a partial fix for this (r2532). If the matcher receives anything besides nil, it'll work was you expect (w/ an InvalidArgument error). I want to solve for nil before I close this, but the slam dunk I was expecting eluded me. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-09-08 00:15 Message: should and should_not both take a matcher (an object that responds to matches?). If no matcher is passed, it handles operators (should == expected). In the case of handling operators, nothing gets passed to should. My thinking is that if anything besides a matcher is passed to should, it should raise an InvalidArgument error. WDYT? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-09-07 22:32 Message: Sorry, my bad - I just saw that you actually had posted on the list first, and having read the mail I understand what you mean. How would you like RSpec to behave in the situation you describe? Can you describe that with a (failing) spec? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-09-07 22:26 Message: I don't understand what you mean, nor is there any complete code here I can execute to reproduce what you say is a bug. Please submit some more complete code on the mailing list to make sure what you're talking about is a bug or not. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13760&group_id=797 From noreply at rubyforge.org Fri Sep 7 23:08:34 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 7 Sep 2007 23:08:34 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-13760 ] False Positives on eql?() Message-ID: <20070908030834.51F305240D5A@rubyforge.org> Bugs item #13760, was opened at 2007-09-07 19:15 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13760&group_id=797 Category: expectation module Group: None Status: Open Resolution: Accepted Priority: 3 Submitted By: Geoffrey Wiseman (diathesis) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: False Positives on eql?() Initial Comment: I accidentally typed: ob.should eql?(something) This passed incorrectly. It seems to be that I've essentially compared the 'something' value to the behavior object, and generated a false; by way of example, this also passes: ob.should false Both of these are presumably dangerous false positives, particularly the former that's one keystroke away from the valid approach, and in keeping with eql? elsewhere, so it's an easy mistake to make. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-08 03:08 Message: Sorry - not an InvalidArgument error - just a NoMethod for now - at least you won't get a false positive on eql?(). ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-09-08 03:03 Message: I just committed a partial fix for this (r2532). If the matcher receives anything besides nil, it'll work was you expect (w/ an InvalidArgument error). I want to solve for nil before I close this, but the slam dunk I was expecting eluded me. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-09-08 00:15 Message: should and should_not both take a matcher (an object that responds to matches?). If no matcher is passed, it handles operators (should == expected). In the case of handling operators, nothing gets passed to should. My thinking is that if anything besides a matcher is passed to should, it should raise an InvalidArgument error. WDYT? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-09-07 22:32 Message: Sorry, my bad - I just saw that you actually had posted on the list first, and having read the mail I understand what you mean. How would you like RSpec to behave in the situation you describe? Can you describe that with a (failing) spec? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-09-07 22:26 Message: I don't understand what you mean, nor is there any complete code here I can execute to reproduce what you say is a bug. Please submit some more complete code on the mailing list to make sure what you're talking about is a bug or not. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13760&group_id=797 From noreply at rubyforge.org Sat Sep 8 10:34:24 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 8 Sep 2007 10:34:24 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-13760 ] False Positives on eql?() Message-ID: <20070908143424.46B8B52409C0@rubyforge.org> Bugs item #13760, was opened at 2007-09-07 19:15 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13760&group_id=797 Category: expectation module Group: None Status: Open Resolution: Accepted Priority: 3 Submitted By: Geoffrey Wiseman (diathesis) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: False Positives on eql?() Initial Comment: I accidentally typed: ob.should eql?(something) This passed incorrectly. It seems to be that I've essentially compared the 'something' value to the behavior object, and generated a false; by way of example, this also passes: ob.should false Both of these are presumably dangerous false positives, particularly the former that's one keystroke away from the valid approach, and in keeping with eql? elsewhere, so it's an easy mistake to make. ---------------------------------------------------------------------- >Comment By: Geoffrey Wiseman (diathesis) Date: 2007-09-08 14:34 Message: Not a problem; the bug could have been more clear, I was relying on the message to the list, but I woulda been happy to set up a quick example. Something like David describes seems sensible if that works. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-09-08 03:08 Message: Sorry - not an InvalidArgument error - just a NoMethod for now - at least you won't get a false positive on eql?(). ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-09-08 03:03 Message: I just committed a partial fix for this (r2532). If the matcher receives anything besides nil, it'll work was you expect (w/ an InvalidArgument error). I want to solve for nil before I close this, but the slam dunk I was expecting eluded me. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-09-08 00:15 Message: should and should_not both take a matcher (an object that responds to matches?). If no matcher is passed, it handles operators (should == expected). In the case of handling operators, nothing gets passed to should. My thinking is that if anything besides a matcher is passed to should, it should raise an InvalidArgument error. WDYT? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-09-07 22:32 Message: Sorry, my bad - I just saw that you actually had posted on the list first, and having read the mail I understand what you mean. How would you like RSpec to behave in the situation you describe? Can you describe that with a (failing) spec? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-09-07 22:26 Message: I don't understand what you mean, nor is there any complete code here I can execute to reproduce what you say is a bug. Please submit some more complete code on the mailing list to make sure what you're talking about is a bug or not. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13760&group_id=797 From rupert_apsc at rupespad.com Sat Sep 8 11:29:58 2007 From: rupert_apsc at rupespad.com (rupert) Date: Sat, 8 Sep 2007 16:29:58 +0100 Subject: [rspec-devel] Trac instead of Rubyforge tracker? In-Reply-To: <46DF3ED5.7040109@gmail.com> References: <46DF3ED5.7040109@gmail.com> Message-ID: <9A62F7B1-48AB-49AE-8535-74CE2DDF95D1@rupespad.com> If you'd find an rss feed of commits to the repository would make your life easier, then you can use: http://subtlety.errtheblog.com/ to keep track of things - it works very nicely! Cheers Rupert On 6 Sep 2007, at 00:42, Michael Klishin wrote: > Guys, > > I'm trying to follow RSpec development but constantly find out that I > have no time to read all emails from dev list and read commit logs / > source changes. > > Maybe it makes sense to set up Trac? Beside being a bit better at > tracking requests and bug reports it has Timeline and Roadmap that > save > huge amount of time compared to SVN logs and source digging. > > WDYT? > > -- > MK > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From noreply at rubyforge.org Sat Sep 8 14:13:12 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 8 Sep 2007 14:13:12 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-13777 ] run last example action in textmate bundle Message-ID: <20070908181312.9FA955240A45@rubyforge.org> Patches item #13777, was opened at 2007-09-08 11:13 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13777&group_id=797 Category: RSpec.tmbundle Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jeremy Stell-Smith (stellsmi) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: run last example action in textmate bundle Initial Comment: This patch records every action you do in the textmate plugin and will rerun it. For example, go to a file, run a spec, go to a different file, and then cmd-shift-i, the last spec will be run ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13777&group_id=797 From noreply at rubyforge.org Sat Sep 8 17:46:23 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 8 Sep 2007 17:46:23 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-13777 ] run last example action in textmate bundle Message-ID: <20070908214623.2D2B45240A9D@rubyforge.org> Patches item #13777, was opened at 2007-09-08 14:13 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13777&group_id=797 Category: RSpec.tmbundle Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jeremy Stell-Smith (stellsmi) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: run last example action in textmate bundle Initial Comment: This patch records every action you do in the textmate plugin and will rerun it. For example, go to a file, run a spec, go to a different file, and then cmd-shift-i, the last spec will be run ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-09-08 17:46 Message: You forgot to check the box when attaching the patch Jeremy :-/ ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13777&group_id=797 From lists-rspec at shopwatch.org Sat Sep 8 17:52:07 2007 From: lists-rspec at shopwatch.org (Jay Levitt) Date: Sat, 08 Sep 2007 17:52:07 -0400 Subject: [rspec-devel] [ rspec-Patches-13777 ] run last example action in textmate bundle In-Reply-To: <20070908214623.2D2B45240A9D@rubyforge.org> References: <20070908214623.2D2B45240A9D@rubyforge.org> Message-ID: <46E31987.5060608@shopwatch.org> On 9/8/2007 5:46 PM, noreply at rubyforge.org wrote: >> Comment By: Aslak Helles?y (aslak_hellesoy) > Date: 2007-09-08 17:46 > > Message: > You forgot to check the box when attaching the patch Jeremy :-/ Man, does this happen a lot lately. But if it makes people feel any better, GForge isn't any better at using their own product than we are - the latest GForge release didn't get a "news" item, nor does it have posted release notes. Jay From dchelimsky at gmail.com Sat Sep 8 17:59:51 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 8 Sep 2007 16:59:51 -0500 Subject: [rspec-devel] changes to TextMate bundle Message-ID: <57c63afe0709081459t7d91040bjc637309553250e02@mail.gmail.com> Hi all, I got some help from James Edward Gray II on the RSpec TextMate bundle. For those of you who don't know James, he runs the Ruby Quiz and also maintains the official TM bundle. Per a couple of patches from him and some advice that I acted on, many of the shortcuts have changed. The bad news is you'll have to learn new shortcuts. The good news is that the new shortcuts follow TextMate conventions (which they really should have from the beginning). The other good news is that we may have a chance to get the bundle into the TextMate repo once we get done w/ the current Story Runner merge. Cheers, David From aslak.hellesoy at gmail.com Sat Sep 8 18:03:04 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sun, 9 Sep 2007 00:03:04 +0200 Subject: [rspec-devel] changes to TextMate bundle In-Reply-To: <57c63afe0709081459t7d91040bjc637309553250e02@mail.gmail.com> References: <57c63afe0709081459t7d91040bjc637309553250e02@mail.gmail.com> Message-ID: <8d961d900709081503p158431eft6d1daf051353185e@mail.gmail.com> Excellent! Do you have a quick list of what shortcuts have changed? It might be a good idea to put this in the CHANGES. Aslak On 9/8/07, David Chelimsky wrote: > Hi all, I got some help from James Edward Gray II on the RSpec > TextMate bundle. For those of you who don't know James, he runs the > Ruby Quiz and also maintains the official TM bundle. > > Per a couple of patches from him and some advice that I acted on, many > of the shortcuts have changed. > > The bad news is you'll have to learn new shortcuts. > > The good news is that the new shortcuts follow TextMate conventions > (which they really should have from the beginning). > > The other good news is that we may have a chance to get the bundle > into the TextMate repo once we get done w/ the current Story Runner > merge. > > Cheers, > David > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dchelimsky at gmail.com Sun Sep 9 03:52:14 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 9 Sep 2007 02:52:14 -0500 Subject: [rspec-devel] changes to TextMate bundle In-Reply-To: <8d961d900709081503p158431eft6d1daf051353185e@mail.gmail.com> References: <57c63afe0709081459t7d91040bjc637309553250e02@mail.gmail.com> <8d961d900709081503p158431eft6d1daf051353185e@mail.gmail.com> Message-ID: <57c63afe0709090052w72b0566byc98579713ca4cc44@mail.gmail.com> On 9/8/07, aslak hellesoy wrote: > Excellent! > > Do you have a quick list of what shortcuts have changed? It might be a > good idea to put this in the CHANGES. They pretty much all changed because almost none of them were following the TextMate convention before. I added a description of this to the CHANGES file. David > > Aslak > > On 9/8/07, David Chelimsky wrote: > > Hi all, I got some help from James Edward Gray II on the RSpec > > TextMate bundle. For those of you who don't know James, he runs the > > Ruby Quiz and also maintains the official TM bundle. > > > > Per a couple of patches from him and some advice that I acted on, many > > of the shortcuts have changed. > > > > The bad news is you'll have to learn new shortcuts. > > > > The good news is that the new shortcuts follow TextMate conventions > > (which they really should have from the beginning). > > > > The other good news is that we may have a chance to get the bundle > > into the TextMate repo once we get done w/ the current Story Runner > > merge. > > > > 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 brian.takita at gmail.com Sun Sep 9 06:53:05 2007 From: brian.takita at gmail.com (Brian Takita) Date: Sun, 9 Sep 2007 03:53:05 -0700 Subject: [rspec-devel] Using Test::Unit::AutoRunner to run Example Suite Message-ID: <1d7ddd110709090353n66ec6654gee0646064b91c70@mail.gmail.com> I just checked in a change that makes Test::Unit's AutoRunner run all of the examples you have defined. This is in accordance with our effort to build rspec on top of Test::Unit. The at_exit callback defined in Kernel#behaviour_runner has been removed in preference of using Test::Unit's at_exit callback. This means you will be able to run Test::Unit tests and rspec examples within the same suite! Of course there are some rough edges that need to be smoothed out, but in most cases it should work. We are still using rspec's Reporter and BehaviourRunner to write to output. The Test::Unit::UI::TestRunnerMediator has been extended to get the rspec summary printed. BehaviourRunner#run is still available and used in rspec's pre_commit process. To try out the Test::Unit runner, simply execute one of the examples in rspec. Here is the output of an example. There is a Test::Unit::TestCase and an Example in this file. Notice that the summarys are separate. Loaded suite /home/btakita/workspace/rspec/rspec/spec/spec/runner/test_unit_and_rspec_spec Started .. Finished in 0.000552 seconds. 1 tests, 1 assertions, 0 failures, 0 errors Finished in 0.000534 seconds 1 example, 0 failures I also created an ExampleSuite class, that subclasses TestSuite. I will be going on vacation until next Wednesday. I hope this works out for everybody. Please take a look at the code. I may be a little slow in responding to your emails though, for the next week and a half, though. Brian From noreply at rubyforge.org Sun Sep 9 17:02:51 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 9 Sep 2007 17:02:51 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-13777 ] run last example action in textmate bundle Message-ID: <20070909210251.8D02B5240B0F@rubyforge.org> Patches item #13777, was opened at 2007-09-08 11:13 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13777&group_id=797 Category: RSpec.tmbundle Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jeremy Stell-Smith (stellsmi) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: run last example action in textmate bundle Initial Comment: This patch records every action you do in the textmate plugin and will rerun it. For example, go to a file, run a spec, go to a different file, and then cmd-shift-i, the last spec will be run ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-09-08 14:46 Message: You forgot to check the box when attaching the patch Jeremy :-/ ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13777&group_id=797 From noreply at rubyforge.org Mon Sep 10 02:37:58 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 10 Sep 2007 02:37:58 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-13814 ] RSpec on Rails w/ fixture-scenarios Message-ID: <20070910063758.B8FE8A970006@rubyforge.org> Patches item #13814, was opened at 2007-09-10 15:37 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13814&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Shintaro Kakutani (kakutani) Assigned to: Nobody (None) Summary: RSpec on Rails w/ fixture-scenarios Initial Comment: fixture-scenarios plugin expects 'fixtures_path' is end with a path separator. (In Rails default, fixtures_path is end with '/') see also: http://code.google.com/p/fixture-scenarios/issues/detail?id=2 attach file is patch for spec_helper.rb ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13814&group_id=797 From dchelimsky at gmail.com Mon Sep 10 09:11:16 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 10 Sep 2007 08:11:16 -0500 Subject: [rspec-devel] Trac instead of Rubyforge tracker? In-Reply-To: <9A62F7B1-48AB-49AE-8535-74CE2DDF95D1@rupespad.com> References: <46DF3ED5.7040109@gmail.com> <9A62F7B1-48AB-49AE-8535-74CE2DDF95D1@rupespad.com> Message-ID: <57c63afe0709100611t4ca452b2tbdb955bd41af3572@mail.gmail.com> On 9/8/07, rupert wrote: > If you'd find an rss feed of commits to the repository would make > your life easier, then you can use: > > http://subtlety.errtheblog.com/ > > to keep track of things - it works very nicely! We already have http://subtlety.errtheblog.com/O_o/1e.xml. > > Cheers > > Rupert > > > On 6 Sep 2007, at 00:42, Michael Klishin wrote: > > > Guys, > > > > I'm trying to follow RSpec development but constantly find out that I > > have no time to read all emails from dev list and read commit logs / > > source changes. > > > > Maybe it makes sense to set up Trac? Beside being a bit better at > > tracking requests and bug reports it has Timeline and Roadmap that > > save > > huge amount of time compared to SVN logs and source digging. > > > > WDYT? > > > > -- > > MK > > _______________________________________________ > > 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 Sep 10 09:12:18 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 10 Sep 2007 08:12:18 -0500 Subject: [rspec-devel] Trac instead of Rubyforge tracker? In-Reply-To: <57c63afe0709100611t4ca452b2tbdb955bd41af3572@mail.gmail.com> References: <46DF3ED5.7040109@gmail.com> <9A62F7B1-48AB-49AE-8535-74CE2DDF95D1@rupespad.com> <57c63afe0709100611t4ca452b2tbdb955bd41af3572@mail.gmail.com> Message-ID: <57c63afe0709100612n6f9e7b09y7c644d34f92ee52a@mail.gmail.com> On 9/10/07, David Chelimsky wrote: > On 9/8/07, rupert wrote: > > If you'd find an rss feed of commits to the repository would make > > your life easier, then you can use: > > > > http://subtlety.errtheblog.com/ > > > > to keep track of things - it works very nicely! > We already have http://subtlety.errtheblog.com/O_o/1e.xml, but we have no sort of changes viewer. So you can see when changes happen and what files get changed and even the commit comment, but you can't see the source changes. > > Cheers > > > > Rupert > > > > > > On 6 Sep 2007, at 00:42, Michael Klishin wrote: > > > > > Guys, > > > > > > I'm trying to follow RSpec development but constantly find out that I > > > have no time to read all emails from dev list and read commit logs / > > > source changes. > > > > > > Maybe it makes sense to set up Trac? Beside being a bit better at > > > tracking requests and bug reports it has Timeline and Roadmap that > > > save > > > huge amount of time compared to SVN logs and source digging. > > > > > > WDYT? > > > > > > -- > > > MK > > > _______________________________________________ > > > rspec-devel mailing list > > > rspec-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > From lists-rspec at shopwatch.org Mon Sep 10 10:22:47 2007 From: lists-rspec at shopwatch.org (Jay Levitt) Date: Mon, 10 Sep 2007 10:22:47 -0400 Subject: [rspec-devel] Trac instead of Rubyforge tracker? In-Reply-To: <8d961d900709071515q415c0e71n17046c3fedb3efea@mail.gmail.com> References: <46DF3ED5.7040109@gmail.com> <8d961d900709071515q415c0e71n17046c3fedb3efea@mail.gmail.com> Message-ID: <46E55337.20400@shopwatch.org> On 9/7/2007 6:15 PM, aslak hellesoy wrote: > On 9/6/07, Michael Klishin wrote: >> Guys, >> >> I'm trying to follow RSpec development but constantly find out that I >> have no time to read all emails from dev list and read commit logs / >> source changes. >> >> Maybe it makes sense to set up Trac? Beside being a bit better at >> tracking requests and bug reports it has Timeline and Roadmap that save >> huge amount of time compared to SVN logs and source digging. >> >> WDYT? >> > > Trac needs a local svn, and we can't set it up at Rubyforge. We'd have > to move everything away from rubyforge. Subversion now allows read-only replication, though - but I'm not sure if that takes configuration at rubyforge or if it can all be configured replicatee-side. I'm guessing this would be fairly low-volume, and if so, I could host it on my Linux box here at home - I have a static IP and about 768K upstream bandwidth. If people are really interested I can look into the mirroring stuff. Jay From noreply at rubyforge.org Mon Sep 10 22:56:39 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 10 Sep 2007 22:56:39 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-13829 ] TextMate bundle does not map classes in /lib in a rails app to /spec/lib Message-ID: <20070911025639.C95245240D64@rubyforge.org> Bugs item #13829, was opened at 2007-09-11 02:56 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13829&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: TextMate bundle does not map classes in /lib in a rails app to /spec/lib Initial Comment: In non-rails apps, the TextMate bundle maps files in /lib to files in /spec. Because Rails doesn't put lib under /app (it puts it in the project root), the TextMate bundle expects the specs for classes in /lib to be directly under /spec. RSpec users, however, like to put specs for classes in /lib in /spec/lib. So we need to make the mapping smarter so it knows if it's in a Rails app, and if so correctly maps /lib to /spec/lib. ---------------------------------------------------------------------- You can respond by visit