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 visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13829&group_id=797 From noreply at rubyforge.org Mon Sep 10 23:03:28 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 10 Sep 2007 23:03:28 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-13830 ] TextMate bundle runs examples twice and outputs the command line output as well Message-ID: <20070911030328.1DC385240D64@rubyforge.org> Bugs item #13830, was opened at 2007-09-11 03:03 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13830&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: TextMate bundle runs examples twice and outputs the command line output as well Initial Comment: Trunk rev2559: Now that we've enabled unified spec and test runs, we have some cleanup to do. Open up any foo_spec.rb file and run the file using CMD-R. The output shows what looks like a bunch of Test::Unit output: Loaded suite /tmp/temp_textmate.g66g4G Started followed by a second listing of all of the examples that were run, followed by the normal command line output: Finished in 0.00704 seconds. 0 tests, 0 assertions, 0 failures, 0 errors Finished in 0.00123 seconds 0 examples, 0 failures See the attached screenshot. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13830&group_id=797 From noreply at rubyforge.org Tue Sep 11 00:40:07 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 11 Sep 2007 00:40:07 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-13833 ] ActionView::Helpers::JavaScriptMacrosHelper removed after 1.2.3 Message-ID: <20070911044008.159CD5240D8C@rubyforge.org> Patches item #13833, was opened at 2007-09-11 07:40 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13833&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Yurii Rashkovskii (yrashk) Assigned to: Nobody (None) Summary: ActionView::Helpers::JavaScriptMacrosHelper removed after 1.2.3 Initial Comment: I was updating edge rails today, rspec_on_rails seems to need a small upgrade. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13833&group_id=797 From noreply at rubyforge.org Tue Sep 11 01:06:40 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 11 Sep 2007 01:06:40 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-13833 ] ActionView::Helpers::JavaScriptMacrosHelper removed after 1.2.3 Message-ID: <20070911050643.00B555240D8C@rubyforge.org> Patches item #13833, was opened at 2007-09-11 04:40 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13833&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Yurii Rashkovskii (yrashk) >Assigned to: David Chelimsky (dchelimsky) Summary: ActionView::Helpers::JavaScriptMacrosHelper removed after 1.2.3 Initial Comment: I was updating edge rails today, rspec_on_rails seems to need a small upgrade. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-11 05:06 Message: Applied to r2560 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13833&group_id=797 From noreply at rubyforge.org Tue Sep 11 05:46:24 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 11 Sep 2007 05:46:24 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-13837 ] alias :running, :lambda Message-ID: <20070911094624.37B215240A4D@rubyforge.org> Feature Requests item #13837, was opened at 2007-09-11 09:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13837&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: sudara williams (sudara) Assigned to: Nobody (None) Summary: alias :running, :lambda Initial Comment: For everyday Rspec "reads like english" purposes, aliasing lambda as "running" would make for some fun spec writing: running { something_risky }.should raise_error running { Fancy.operation }.should_not change(@simple, :factor) or even running { to_the_bathroom }.should_not change(person, :weight) describe "A clear spec language" do it "should replace generic lowlevel language with intuitive goodies" do running { 5.to_s }.call.should == lambda { 5.to_s }.call end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13837&group_id=797 From noreply at rubyforge.org Tue Sep 11 05:55:55 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 11 Sep 2007 05:55:55 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-13837 ] alias :running, :lambda Message-ID: <20070911095556.0E0B25240A85@rubyforge.org> Feature Requests item #13837, was opened at 2007-09-11 05:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13837&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: sudara williams (sudara) Assigned to: Nobody (None) Summary: alias :running, :lambda Initial Comment: For everyday Rspec "reads like english" purposes, aliasing lambda as "running" would make for some fun spec writing: running { something_risky }.should raise_error running { Fancy.operation }.should_not change(@simple, :factor) or even running { to_the_bathroom }.should_not change(person, :weight) describe "A clear spec language" do it "should replace generic lowlevel language with intuitive goodies" do running { 5.to_s }.call.should == lambda { 5.to_s }.call end end ---------------------------------------------------------------------- Comment By: Jay Levitt (jaylev) Date: 2007-09-11 05:55 Message: +1!! ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13837&group_id=797 From noreply at rubyforge.org Tue Sep 11 17:26:10 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 11 Sep 2007 17:26:10 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-13837 ] alias :running, :lambda Message-ID: <20070911212610.8F2DC52409E9@rubyforge.org> Feature Requests item #13837, was opened at 2007-09-11 09:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13837&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: sudara williams (sudara) Assigned to: Nobody (None) Summary: alias :running, :lambda Initial Comment: For everyday Rspec "reads like english" purposes, aliasing lambda as "running" would make for some fun spec writing: running { something_risky }.should raise_error running { Fancy.operation }.should_not change(@simple, :factor) or even running { to_the_bathroom }.should_not change(person, :weight) describe "A clear spec language" do it "should replace generic lowlevel language with intuitive goodies" do running { 5.to_s }.call.should == lambda { 5.to_s }.call end end ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-09-11 21:26 Message: How about run { do_something }.should raise_error ? ---------------------------------------------------------------------- Comment By: Jay Levitt (jaylev) Date: 2007-09-11 09:55 Message: +1!! ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13837&group_id=797 From noreply at rubyforge.org Tue Sep 11 17:27:27 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 11 Sep 2007 17:27:27 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-13856 ] Show Pending Messages in RSpec Report Message-ID: <20070911212727.F330D52409E9@rubyforge.org> Feature Requests item #13856, was opened at 2007-09-11 21:27 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13856&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Geoffrey Wiseman (diathesis) Assigned to: Nobody (None) Summary: Show Pending Messages in RSpec Report Initial Comment: When the spec contains an explicit pending message, e.g.: describe "Secure passwords with MD5" do pending "Waiting on selection of an MD5 library." end It'd be nice if this were visible in the RSpec HTML report. Currently, the HTML report contains 'Secure passwords with MD5' as pending, but does not add the explanation as to why. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13856&group_id=797 From noreply at rubyforge.org Tue Sep 11 17:27:55 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 11 Sep 2007 17:27:55 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-13837 ] alias :running, :lambda Message-ID: <20070911212755.CF5745240DB2@rubyforge.org> Feature Requests item #13837, was opened at 2007-09-11 05:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13837&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: sudara williams (sudara) Assigned to: Nobody (None) Summary: alias :running, :lambda Initial Comment: For everyday Rspec "reads like english" purposes, aliasing lambda as "running" would make for some fun spec writing: running { something_risky }.should raise_error running { Fancy.operation }.should_not change(@simple, :factor) or even running { to_the_bathroom }.should_not change(person, :weight) describe "A clear spec language" do it "should replace generic lowlevel language with intuitive goodies" do running { 5.to_s }.call.should == lambda { 5.to_s }.call end end ---------------------------------------------------------------------- Comment By: Jay Levitt (jaylev) Date: 2007-09-11 17:27 Message: "run" doesn't read as English, though... running {this}.should do_that ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-09-11 17:26 Message: How about run { do_something }.should raise_error ? ---------------------------------------------------------------------- Comment By: Jay Levitt (jaylev) Date: 2007-09-11 05:55 Message: +1!! ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13837&group_id=797 From noreply at rubyforge.org Tue Sep 11 17:29:48 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 11 Sep 2007 17:29:48 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-13857 ] Show/Hide Spec Source in RSpec HTML Report Message-ID: <20070911212948.DD6035240DB2@rubyforge.org> Feature Requests item #13857, was opened at 2007-09-11 21:29 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13857&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Geoffrey Wiseman (diathesis) Assigned to: Nobody (None) Summary: Show/Hide Spec Source in RSpec HTML Report Initial Comment: It would be nice to be able to use DHTML expansion to see the source of the spec, sometimes. When we're doing walkthroughs with the customer representative, it's useful for him to be able to see the source as well as the descriptions. Sometimes, this might be a sign that we haven't achieved as fine a granularity as we should in the descriptions, but when he has questions about the details, it would still be nice to be able to bring it up. I wouldn't want to clutter the report with this, but if it were handled through judicious use of DHTML, it might be possible to accomplish this with minimal ugliness. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13857&group_id=797 From noreply at rubyforge.org Tue Sep 11 18:10:26 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 11 Sep 2007 18:10:26 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-13837 ] alias :running, :lambda Message-ID: <20070911221027.165975240DB2@rubyforge.org> Feature Requests item #13837, was opened at 2007-09-11 05:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13837&group_id=797 Category: expectation module Group: None Status: Open Priority: 3 Submitted By: sudara williams (sudara) Assigned to: Nobody (None) Summary: alias :running, :lambda Initial Comment: For everyday Rspec "reads like english" purposes, aliasing lambda as "running" would make for some fun spec writing: running { something_risky }.should raise_error running { Fancy.operation }.should_not change(@simple, :factor) or even running { to_the_bathroom }.should_not change(person, :weight) describe "A clear spec language" do it "should replace generic lowlevel language with intuitive goodies" do running { 5.to_s }.call.should == lambda { 5.to_s }.call end end ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-09-11 18:10 Message: -1 While I value readability, I value idioms more. lambda is at ruby's core and it's a common idiom - I don't want an alias for it, but everyone is free to make their own alias. ---------------------------------------------------------------------- Comment By: Jay Levitt (jaylev) Date: 2007-09-11 17:27 Message: "run" doesn't read as English, though... running {this}.should do_that ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-09-11 17:26 Message: How about run { do_something }.should raise_error ? ---------------------------------------------------------------------- Comment By: Jay Levitt (jaylev) Date: 2007-09-11 05:55 Message: +1!! ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13837&group_id=797 From noreply at rubyforge.org Tue Sep 11 18:19:28 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 11 Sep 2007 18:19:28 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-13837 ] alias :running, :lambda Message-ID: <20070911221928.CC2085240E25@rubyforge.org> Feature Requests item #13837, was opened at 2007-09-11 09:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13837&group_id=797 Category: expectation module Group: None >Status: Closed Priority: 3 Submitted By: sudara williams (sudara) >Assigned to: David Chelimsky (dchelimsky) Summary: alias :running, :lambda Initial Comment: For everyday Rspec "reads like english" purposes, aliasing lambda as "running" would make for some fun spec writing: running { something_risky }.should raise_error running { Fancy.operation }.should_not change(@simple, :factor) or even running { to_the_bathroom }.should_not change(person, :weight) describe "A clear spec language" do it "should replace generic lowlevel language with intuitive goodies" do running { 5.to_s }.call.should == lambda { 5.to_s }.call end end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-11 22:19 Message: Based on recent conversations re: internal vs external DSL's, I have to go w/ Aslak on this one. It's important that your customers understand the Strings you pass to describe and it. It's important that your fellow programmers understand the code in the block. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-09-11 22:10 Message: -1 While I value readability, I value idioms more. lambda is at ruby's core and it's a common idiom - I don't want an alias for it, but everyone is free to make their own alias. ---------------------------------------------------------------------- Comment By: Jay Levitt (jaylev) Date: 2007-09-11 21:27 Message: "run" doesn't read as English, though... running {this}.should do_that ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-09-11 21:26 Message: How about run { do_something }.should raise_error ? ---------------------------------------------------------------------- Comment By: Jay Levitt (jaylev) Date: 2007-09-11 09:55 Message: +1!! ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13837&group_id=797 From noreply at rubyforge.org Tue Sep 11 21:40:17 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 11 Sep 2007 21:40:17 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-13837 ] alias :running, :lambda Message-ID: <20070912014017.A606F5240E16@rubyforge.org> Feature Requests item #13837, was opened at 2007-09-11 09:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13837&group_id=797 Category: expectation module Group: None Status: Closed Priority: 3 Submitted By: sudara williams (sudara) Assigned to: David Chelimsky (dchelimsky) Summary: alias :running, :lambda Initial Comment: For everyday Rspec "reads like english" purposes, aliasing lambda as "running" would make for some fun spec writing: running { something_risky }.should raise_error running { Fancy.operation }.should_not change(@simple, :factor) or even running { to_the_bathroom }.should_not change(person, :weight) describe "A clear spec language" do it "should replace generic lowlevel language with intuitive goodies" do running { 5.to_s }.call.should == lambda { 5.to_s }.call end end ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-09-12 01:40 Message: I must say I agree with Aslak, because lambda screams in my face *delayed evaluation* The reason I suggested run was that a co-worker (who is new to rspec) suggested it. He comes from Test::Unit and keeps on making this mistake: my_method.should raise_error If the code doesn't raise an error (say it returns nil) - then the error message will read something like the following: NoMethodError: nil.call ... (Obviously here the proc is trying to be called...) So maybe a better error message would work in this case? (ps: What is the internal vs. external DSL conversation?) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-09-11 22:19 Message: Based on recent conversations re: internal vs external DSL's, I have to go w/ Aslak on this one. It's important that your customers understand the Strings you pass to describe and it. It's important that your fellow programmers understand the code in the block. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-09-11 22:10 Message: -1 While I value readability, I value idioms more. lambda is at ruby's core and it's a common idiom - I don't want an alias for it, but everyone is free to make their own alias. ---------------------------------------------------------------------- Comment By: Jay Levitt (jaylev) Date: 2007-09-11 21:27 Message: "run" doesn't read as English, though... running {this}.should do_that ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-09-11 21:26 Message: How about run { do_something }.should raise_error ? ---------------------------------------------------------------------- Comment By: Jay Levitt (jaylev) Date: 2007-09-11 09:55 Message: +1!! ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13837&group_id=797 From noreply at rubyforge.org Wed Sep 12 03:14:40 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 12 Sep 2007 03:14:40 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11536 ] controller.should render_template must be defined after the action Message-ID: <20070912071440.42B595240E67@rubyforge.org> Bugs item #11536, was opened at 2007-06-12 18:25 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11536&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: courtenay 3 (court3nay) Assigned to: Nobody (None) Summary: controller.should render_template must be defined after the action Initial Comment: this fails: it "should render index.rhtml" do response.should render_template(:index) do_get end this works: it "should render index.rhtml" do do_get response.should render_template(:index) end Here's my patch; it doesn't "feel" right to me, since there's no other error handling in that file. Index: lib/spec/rails/matchers/render_template.rb =================================================================== --- lib/spec/rails/matchers/render_template.rb (revision 1429) +++ lib/spec/rails/matchers/render_template.rb (working copy) @@ -9,6 +9,9 @@ end def matches?(response) + unless response.respond_to?:rendered_file + raise "The response has not yet rendered or is not a Response object. This matcher (render_template) must be defined after the controller action is called." + end @actual = response.rendered_file(!expected.include?('/')) actual == expected end ---------------------------------------------------------------------- Comment By: Bryan Helmkamp (brynary) Date: 2007-09-12 03:14 Message: Perhaps the matcher should be renamed from render_file to have_rendered_file. Thoughts? If this sounds good, I'll write a patch. ---------------------------------------------------------------------- Comment By: courtenay 3 (court3nay) Date: 2007-06-12 18:34 Message: the patch doesn't actually work like I intended, but I can't see a way of checking that the order is correct ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11536&group_id=797 From noreply at rubyforge.org Wed Sep 12 03:22:53 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 12 Sep 2007 03:22:53 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11536 ] controller.should render_template must be defined after the action Message-ID: <20070912072253.4A0D35240E6F@rubyforge.org> Bugs item #11536, was opened at 2007-06-12 22:25 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11536&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: courtenay 3 (court3nay) Assigned to: Nobody (None) Summary: controller.should render_template must be defined after the action Initial Comment: this fails: it "should render index.rhtml" do response.should render_template(:index) do_get end this works: it "should render index.rhtml" do do_get response.should render_template(:index) end Here's my patch; it doesn't "feel" right to me, since there's no other error handling in that file. Index: lib/spec/rails/matchers/render_template.rb =================================================================== --- lib/spec/rails/matchers/render_template.rb (revision 1429) +++ lib/spec/rails/matchers/render_template.rb (working copy) @@ -9,6 +9,9 @@ end def matches?(response) + unless response.respond_to?:rendered_file + raise "The response has not yet rendered or is not a Response object. This matcher (render_template) must be defined after the controller action is called." + end @actual = response.rendered_file(!expected.include?('/')) actual == expected end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-12 07:22 Message: It's a bit too late for that Bryan. We're committed to not changing these. We could alias it, but I'd prefer to avoid going down that path. I think we need to figure out a way to give the right feedback when it's used incorrectly. ---------------------------------------------------------------------- Comment By: Bryan Helmkamp (brynary) Date: 2007-09-12 07:14 Message: Perhaps the matcher should be renamed from render_file to have_rendered_file. Thoughts? If this sounds good, I'll write a patch. ---------------------------------------------------------------------- Comment By: courtenay 3 (court3nay) Date: 2007-06-12 22:34 Message: the patch doesn't actually work like I intended, but I can't see a way of checking that the order is correct ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11536&group_id=797 From noreply at rubyforge.org Wed Sep 12 08:39:35 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 12 Sep 2007 08:39:35 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-13837 ] alias :running, :lambda Message-ID: <20070912123935.E4B6A5240B0B@rubyforge.org> Feature Requests item #13837, was opened at 2007-09-11 09:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13837&group_id=797 Category: expectation module Group: None Status: Closed Priority: 3 Submitted By: sudara williams (sudara) Assigned to: David Chelimsky (dchelimsky) Summary: alias :running, :lambda Initial Comment: For everyday Rspec "reads like english" purposes, aliasing lambda as "running" would make for some fun spec writing: running { something_risky }.should raise_error running { Fancy.operation }.should_not change(@simple, :factor) or even running { to_the_bathroom }.should_not change(person, :weight) describe "A clear spec language" do it "should replace generic lowlevel language with intuitive goodies" do running { 5.to_s }.call.should == lambda { 5.to_s }.call end end ---------------------------------------------------------------------- >Comment By: sudara williams (sudara) Date: 2007-09-12 12:39 Message: Awwww.... The only thing lambda screens in my face is "what a terribly unhelpful name!" I'll relax ;) A programmer's love for the obscure is only a variation of human love for the familiar. My point with Rspec: lambda (despite it being a familiar idiom to non-beginners) has a single use in Rspec - to specify a code block that will be run as a part of evaluating a more complex match. In other words, Rspec needs to run some code before and after this block in order to do it's magic. Long story short, my opinion Rspec asks me to hack itself using a technique that just aint readable, making for a heavy feeling. >From a DSL point of view (aka, learning Rspec) there is no real way to differentiate matchers that need it. The More Complicated Ones. Idiomatically, lambda is being used as a helper within Rspec internals. Using it, Rspec can go about wrapping my lambda with some code and then executing it. That is the idiom in place here, and that idiom is much better expressed as "running." After all, this is the DSL we'd really love to have, eh? Basket.add_apple.should change(@fruit, :count Thanks for listening, and I'll walk away from this happy to learn and without expecting um that anything.should change ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-09-12 01:40 Message: I must say I agree with Aslak, because lambda screams in my face *delayed evaluation* The reason I suggested run was that a co-worker (who is new to rspec) suggested it. He comes from Test::Unit and keeps on making this mistake: my_method.should raise_error If the code doesn't raise an error (say it returns nil) - then the error message will read something like the following: NoMethodError: nil.call ... (Obviously here the proc is trying to be called...) So maybe a better error message would work in this case? (ps: What is the internal vs. external DSL conversation?) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-09-11 22:19 Message: Based on recent conversations re: internal vs external DSL's, I have to go w/ Aslak on this one. It's important that your customers understand the Strings you pass to describe and it. It's important that your fellow programmers understand the code in the block. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-09-11 22:10 Message: -1 While I value readability, I value idioms more. lambda is at ruby's core and it's a common idiom - I don't want an alias for it, but everyone is free to make their own alias. ---------------------------------------------------------------------- Comment By: Jay Levitt (jaylev) Date: 2007-09-11 21:27 Message: "run" doesn't read as English, though... running {this}.should do_that ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-09-11 21:26 Message: How about run { do_something }.should raise_error ? ---------------------------------------------------------------------- Comment By: Jay Levitt (jaylev) Date: 2007-09-11 09:55 Message: +1!! ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13837&group_id=797 From noreply at rubyforge.org Wed Sep 12 09:20:03 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 12 Sep 2007 09:20:03 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-13837 ] alias :running, :lambda Message-ID: <20070912132003.4AA665240B0B@rubyforge.org> Feature Requests item #13837, was opened at 2007-09-11 02:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13837&group_id=797 Category: expectation module Group: None Status: Closed Priority: 3 Submitted By: sudara williams (sudara) Assigned to: David Chelimsky (dchelimsky) Summary: alias :running, :lambda Initial Comment: For everyday Rspec "reads like english" purposes, aliasing lambda as "running" would make for some fun spec writing: running { something_risky }.should raise_error running { Fancy.operation }.should_not change(@simple, :factor) or even running { to_the_bathroom }.should_not change(person, :weight) describe "A clear spec language" do it "should replace generic lowlevel language with intuitive goodies" do running { 5.to_s }.call.should == lambda { 5.to_s }.call end end ---------------------------------------------------------------------- Comment By: Matt Aimonetti (matt_a) Date: 2007-09-12 06:20 Message: I agree with Aslak. lambda is part of the Ruby language, it's well documented and if you are a Ruby developer you surely know and understand what it does. Also, aliases are easy enough to add so it shouldn't be a big deal for you to add your own. ---------------------------------------------------------------------- Comment By: sudara williams (sudara) Date: 2007-09-12 05:39 Message: Awwww.... The only thing lambda screens in my face is "what a terribly unhelpful name!" I'll relax ;) A programmer's love for the obscure is only a variation of human love for the familiar. My point with Rspec: lambda (despite it being a familiar idiom to non-beginners) has a single use in Rspec - to specify a code block that will be run as a part of evaluating a more complex match. In other words, Rspec needs to run some code before and after this block in order to do it's magic. Long story short, my opinion Rspec asks me to hack itself using a technique that just aint readable, making for a heavy feeling. >From a DSL point of view (aka, learning Rspec) there is no real way to differentiate matchers that need it. The More Complicated Ones. Idiomatically, lambda is being used as a helper within Rspec internals. Using it, Rspec can go about wrapping my lambda with some code and then executing it. That is the idiom in place here, and that idiom is much better expressed as "running." After all, this is the DSL we'd really love to have, eh? Basket.add_apple.should change(@fruit, :count Thanks for listening, and I'll walk away from this happy to learn and without expecting um that anything.should change ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-09-11 18:40 Message: I must say I agree with Aslak, because lambda screams in my face *delayed evaluation* The reason I suggested run was that a co-worker (who is new to rspec) suggested it. He comes from Test::Unit and keeps on making this mistake: my_method.should raise_error If the code doesn't raise an error (say it returns nil) - then the error message will read something like the following: NoMethodError: nil.call ... (Obviously here the proc is trying to be called...) So maybe a better error message would work in this case? (ps: What is the internal vs. external DSL conversation?) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-09-11 15:19 Message: Based on recent conversations re: internal vs external DSL's, I have to go w/ Aslak on this one. It's important that your customers understand the Strings you pass to describe and it. It's important that your fellow programmers understand the code in the block. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-09-11 15:10 Message: -1 While I value readability, I value idioms more. lambda is at ruby's core and it's a common idiom - I don't want an alias for it, but everyone is free to make their own alias. ---------------------------------------------------------------------- Comment By: Jay Levitt (jaylev) Date: 2007-09-11 14:27 Message: "run" doesn't read as English, though... running {this}.should do_that ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-09-11 14:26 Message: How about run { do_something }.should raise_error ? ---------------------------------------------------------------------- Comment By: Jay Levitt (jaylev) Date: 2007-09-11 02:55 Message: +1!! ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13837&group_id=797 From dan at tastapod.com Wed Sep 12 09:30:29 2007 From: dan at tastapod.com (Dan North) Date: Wed, 12 Sep 2007 14:30:29 +0100 Subject: [rspec-devel] Trac instead of Rubyforge tracker? In-Reply-To: <46E55337.20400@shopwatch.org> References: <46DF3ED5.7040109@gmail.com> <8d961d900709071515q415c0e71n17046c3fedb3efea@mail.gmail.com> <46E55337.20400@shopwatch.org> Message-ID: <46E7E9F5.9090807@tastapod.com> If we're thinking about that route, I have a linux VPS on the uk backbone (so it's highly available and has something like 1Gbit network access, and won't get capped by Sky!). I'm happy to host subversion and trac there. We can use tailor to pull down the repository and all its history, which is a pretty straightforward operation. Let me know - I'm in Linux sysadmin mode at the moment anyway, so it wouldn't be a very big chore. (We could host the rspec.org domain off it too, if any of you guys own that?). Cheers, Dan Jay Levitt wrote: > 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 > > > _______________________________________________ > 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/20070912/2403cc86/attachment.html From dan at tastapod.com Wed Sep 12 09:34:18 2007 From: dan at tastapod.com (Dan North) Date: Wed, 12 Sep 2007 14:34:18 +0100 Subject: [rspec-devel] Trac instead of Rubyforge tracker? In-Reply-To: <46E55337.20400@shopwatch.org> References: <46DF3ED5.7040109@gmail.com> <8d961d900709071515q415c0e71n17046c3fedb3efea@mail.gmail.com> <46E55337.20400@shopwatch.org> Message-ID: <46E7EADA.4090203@tastapod.com> If we're thinking about that route, I have a linux VPS on the uk backbone (so it's highly available and has something like 1Gbit network access, and won't get capped by Sky!). I'm happy to host subversion and trac there. We can use tailor to pull down the repository and all its history, which is a pretty straightforward operation. Let me know - I'm in Linux sysadmin mode at the moment anyway, so it wouldn't be a very big chore. (We could host the rspec.org domain off it too, if any of you guys own that?). Cheers, Dan Jay Levitt wrote: > 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 > > > _______________________________________________ > 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/20070912/dd2e9489/attachment.html From noreply at rubyforge.org Wed Sep 12 10:08:09 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 12 Sep 2007 10:08:09 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-13837 ] alias :running, :lambda Message-ID: <20070912140809.599D65240B6C@rubyforge.org> Feature Requests item #13837, was opened at 2007-09-11 09:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13837&group_id=797 Category: expectation module Group: None Status: Closed Priority: 3 Submitted By: sudara williams (sudara) Assigned to: David Chelimsky (dchelimsky) Summary: alias :running, :lambda Initial Comment: For everyday Rspec "reads like english" purposes, aliasing lambda as "running" would make for some fun spec writing: running { something_risky }.should raise_error running { Fancy.operation }.should_not change(@simple, :factor) or even running { to_the_bathroom }.should_not change(person, :weight) describe "A clear spec language" do it "should replace generic lowlevel language with intuitive goodies" do running { 5.to_s }.call.should == lambda { 5.to_s }.call end end ---------------------------------------------------------------------- >Comment By: sudara williams (sudara) Date: 2007-09-12 14:08 Message: Yikes! lambda = Ruby Sudara.should alias(:lambda) if Sudara.doesnt_like_it Got it. My hope is that you guys can read something deeper in my request. ---------------------------------------------------------------------- Comment By: Matt Aimonetti (matt_a) Date: 2007-09-12 13:20 Message: I agree with Aslak. lambda is part of the Ruby language, it's well documented and if you are a Ruby developer you surely know and understand what it does. Also, aliases are easy enough to add so it shouldn't be a big deal for you to add your own. ---------------------------------------------------------------------- Comment By: sudara williams (sudara) Date: 2007-09-12 12:39 Message: Awwww.... The only thing lambda screens in my face is "what a terribly unhelpful name!" I'll relax ;) A programmer's love for the obscure is only a variation of human love for the familiar. My point with Rspec: lambda (despite it being a familiar idiom to non-beginners) has a single use in Rspec - to specify a code block that will be run as a part of evaluating a more complex match. In other words, Rspec needs to run some code before and after this block in order to do it's magic. Long story short, my opinion Rspec asks me to hack itself using a technique that just aint readable, making for a heavy feeling. >From a DSL point of view (aka, learning Rspec) there is no real way to differentiate matchers that need it. The More Complicated Ones. Idiomatically, lambda is being used as a helper within Rspec internals. Using it, Rspec can go about wrapping my lambda with some code and then executing it. That is the idiom in place here, and that idiom is much better expressed as "running." After all, this is the DSL we'd really love to have, eh? Basket.add_apple.should change(@fruit, :count Thanks for listening, and I'll walk away from this happy to learn and without expecting um that anything.should change ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-09-12 01:40 Message: I must say I agree with Aslak, because lambda screams in my face *delayed evaluation* The reason I suggested run was that a co-worker (who is new to rspec) suggested it. He comes from Test::Unit and keeps on making this mistake: my_method.should raise_error If the code doesn't raise an error (say it returns nil) - then the error message will read something like the following: NoMethodError: nil.call ... (Obviously here the proc is trying to be called...) So maybe a better error message would work in this case? (ps: What is the internal vs. external DSL conversation?) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-09-11 22:19 Message: Based on recent conversations re: internal vs external DSL's, I have to go w/ Aslak on this one. It's important that your customers understand the Strings you pass to describe and it. It's important that your fellow programmers understand the code in the block. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-09-11 22:10 Message: -1 While I value readability, I value idioms more. lambda is at ruby's core and it's a common idiom - I don't want an alias for it, but everyone is free to make their own alias. ---------------------------------------------------------------------- Comment By: Jay Levitt (jaylev) Date: 2007-09-11 21:27 Message: "run" doesn't read as English, though... running {this}.should do_that ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-09-11 21:26 Message: How about run { do_something }.should raise_error ? ---------------------------------------------------------------------- Comment By: Jay Levitt (jaylev) Date: 2007-09-11 09:55 Message: +1!! ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13837&group_id=797 From noreply at rubyforge.org Wed Sep 12 11:37:11 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 12 Sep 2007 11:37:11 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-13837 ] alias :running, :lambda Message-ID: <20070912153712.105DB5240B88@rubyforge.org> Feature Requests item #13837, was opened at 2007-09-11 09:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13837&group_id=797 Category: expectation module Group: None Status: Closed Priority: 3 Submitted By: sudara williams (sudara) Assigned to: David Chelimsky (dchelimsky) Summary: alias :running, :lambda Initial Comment: For everyday Rspec "reads like english" purposes, aliasing lambda as "running" would make for some fun spec writing: running { something_risky }.should raise_error running { Fancy.operation }.should_not change(@simple, :factor) or even running { to_the_bathroom }.should_not change(person, :weight) describe "A clear spec language" do it "should replace generic lowlevel language with intuitive goodies" do running { 5.to_s }.call.should == lambda { 5.to_s }.call end end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-12 15:37 Message: "My hope is that you guys can read something deeper in my request" strikes me as patronizing and not very helpful. If you're interested in helping us to learn something that we may be missing, please continue to do so respectfully, by example. As I see it, you would like to see RSpec read even more like English. The complicating factor is that we're really trying to ride a fine line between English and Ruby. The examples are supposed to serve as documentation at both high and low levels. At the high level, we have the strings that allow you to express things at whatever level is appropriate for the audience. If you're spec'ing a class, you can choose terminology that speaks to developers. If you're spec'ing a more high-level behaviour, something you might collaborate with customers on, you can choose domain specific terminology. At the low level, we have code. In the end, that code needs to tell its story to the developer. In fact, it has been argued that sexy little tricks like collection.should be_empty does not serve well as documentation for the developer. I believe that this argument has merit. Early on, we recognized that should_equal, while aesthetically pleasing, also hid the Ruby story, which is that there are several ways to define equality, each with their own semantics and significance. In this case we preferred Ruby over English, supporting methods that align directly to Ruby methods. In terms of lambda, this is definitely a Ruby term. No argument there. The question then becomes a matter of goals. We can talk about aesthetics, but whose aesthetic sense are we serving by using 'running' vs 'lambda'? All of this said, there is another approach that comes closer to something you suggested in a previous comment: Basket.add_apple.should change(@fruit, :count) We can't really support that without getting into continuations (no thank you), and even then I'm not convinced we wouldn't suffer some ugly side effects. That said, we *could* do this: 'Basket.add_apple'.should change('fruit.count') We'd have to eval both strings, which you could argue doesn't help any, but it does read more "ideally." WDYT? ---------------------------------------------------------------------- Comment By: sudara williams (sudara) Date: 2007-09-12 14:08 Message: Yikes! lambda = Ruby Sudara.should alias(:lambda) if Sudara.doesnt_like_it Got it. My hope is that you guys can read something deeper in my request. ---------------------------------------------------------------------- Comment By: Matt Aimonetti (matt_a) Date: 2007-09-12 13:20 Message: I agree with Aslak. lambda is part of the Ruby language, it's well documented and if you are a Ruby developer you surely know and understand what it does. Also, aliases are easy enough to add so it shouldn't be a big deal for you to add your own. ---------------------------------------------------------------------- Comment By: sudara williams (sudara) Date: 2007-09-12 12:39 Message: Awwww.... The only thing lambda screens in my face is "what a terribly unhelpful name!" I'll relax ;) A programmer's love for the obscure is only a variation of human love for the familiar. My point with Rspec: lambda (despite it being a familiar idiom to non-beginners) has a single use in Rspec - to specify a code block that will be run as a part of evaluating a more complex match. In other words, Rspec needs to run some code before and after this block in order to do it's magic. Long story short, my opinion Rspec asks me to hack itself using a technique that just aint readable, making for a heavy feeling. >From a DSL point of view (aka, learning Rspec) there is no real way to differentiate matchers that need it. The More Complicated Ones. Idiomatically, lambda is being used as a helper within Rspec internals. Using it, Rspec can go about wrapping my lambda with some code and then executing it. That is the idiom in place here, and that idiom is much better expressed as "running." After all, this is the DSL we'd really love to have, eh? Basket.add_apple.should change(@fruit, :count Thanks for listening, and I'll walk away from this happy to learn and without expecting um that anything.should change ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-09-12 01:40 Message: I must say I agree with Aslak, because lambda screams in my face *delayed evaluation* The reason I suggested run was that a co-worker (who is new to rspec) suggested it. He comes from Test::Unit and keeps on making this mistake: my_method.should raise_error If the code doesn't raise an error (say it returns nil) - then the error message will read something like the following: NoMethodError: nil.call ... (Obviously here the proc is trying to be called...) So maybe a better error message would work in this case? (ps: What is the internal vs. external DSL conversation?) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-09-11 22:19 Message: Based on recent conversations re: internal vs external DSL's, I have to go w/ Aslak on this one. It's important that your customers understand the Strings you pass to describe and it. It's important that your fellow programmers understand the code in the block. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-09-11 22:10 Message: -1 While I value readability, I value idioms more. lambda is at ruby's core and it's a common idiom - I don't want an alias for it, but everyone is free to make their own alias. ---------------------------------------------------------------------- Comment By: Jay Levitt (jaylev) Date: 2007-09-11 21:27 Message: "run" doesn't read as English, though... running {this}.should do_that ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-09-11 21:26 Message: How about run { do_something }.should raise_error ? ---------------------------------------------------------------------- Comment By: Jay Levitt (jaylev) Date: 2007-09-11 09:55 Message: +1!! ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13837&group_id=797 From dchelimsky at gmail.com Wed Sep 12 11:38:11 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 12 Sep 2007 10:38:11 -0500 Subject: [rspec-devel] Trac instead of Rubyforge tracker? In-Reply-To: <46E7E9F5.9090807@tastapod.com> References: <46DF3ED5.7040109@gmail.com> <8d961d900709071515q415c0e71n17046c3fedb3efea@mail.gmail.com> <46E55337.20400@shopwatch.org> <46E7E9F5.9090807@tastapod.com> Message-ID: <57c63afe0709120838i535ca38bt3cb0a1bf5715ecce@mail.gmail.com> On 9/12/07, Dan North wrote: > > If we're thinking about that route, I have a linux VPS on the uk backbone > (so it's highly available and has something like 1Gbit network access, and > won't get capped by Sky!). > > I'm happy to host subversion and trac there. We can use tailor to pull down > the repository and all its history, which is a pretty straightforward > operation. > > Let me know - I'm in Linux sysadmin mode at the moment anyway, so it > wouldn't be a very big chore. (We could host the rspec.org domain off it > too, if any of you guys own that?). rspec.org is taken. I think it's been so for a while. I've emailed the guy to see if he's interested in letting it go. As for tools, I've found trac to be a bit bloated. I'd like to look at warehouse/lighthouse. Cheers, David > > Cheers, > Dan > > > > Jay Levitt wrote: > 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 > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From noreply at rubyforge.org Wed Sep 12 11:47:43 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 12 Sep 2007 11:47:43 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-13837 ] alias :running, :lambda Message-ID: <20070912154743.7E8605240C16@rubyforge.org> Feature Requests item #13837, was opened at 2007-09-11 05:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13837&group_id=797 Category: expectation module Group: None Status: Closed Priority: 3 Submitted By: sudara williams (sudara) Assigned to: David Chelimsky (dchelimsky) Summary: alias :running, :lambda Initial Comment: For everyday Rspec "reads like english" purposes, aliasing lambda as "running" would make for some fun spec writing: running { something_risky }.should raise_error running { Fancy.operation }.should_not change(@simple, :factor) or even running { to_the_bathroom }.should_not change(person, :weight) describe "A clear spec language" do it "should replace generic lowlevel language with intuitive goodies" do running { 5.to_s }.call.should == lambda { 5.to_s }.call end end ---------------------------------------------------------------------- Comment By: Jay Levitt (jaylev) Date: 2007-09-12 11:47 Message: Oo, that's pretty too. I understand that lambda is a common Ruby-ism, but at the moment, nothing I do (or expect to do in Rails) needs it -except- for rspec, and I don't like to have to think in metaprogramming mode unless I need to. If the eval method is easy to code, works the same as lambda does today, doesn't create any maintenance nightmares, etc., I'd +1 that.. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-09-12 11:37 Message: "My hope is that you guys can read something deeper in my request" strikes me as patronizing and not very helpful. If you're interested in helping us to learn something that we may be missing, please continue to do so respectfully, by example. As I see it, you would like to see RSpec read even more like English. The complicating factor is that we're really trying to ride a fine line between English and Ruby. The examples are supposed to serve as documentation at both high and low levels. At the high level, we have the strings that allow you to express things at whatever level is appropriate for the audience. If you're spec'ing a class, you can choose terminology that speaks to developers. If you're spec'ing a more high-level behaviour, something you might collaborate with customers on, you can choose domain specific terminology. At the low level, we have code. In the end, that code needs to tell its story to the developer. In fact, it has been argued that sexy little tricks like collection.should be_empty does not serve well as documentation for the developer. I believe that this argument has merit. Early on, we recognized that should_equal, while aesthetically pleasing, also hid the Ruby story, which is that there are several ways to define equality, each with their own semantics and significance. In this case we preferred Ruby over English, supporting methods that align directly to Ruby methods. In terms of lambda, this is definitely a Ruby term. No argument there. The question then becomes a matter of goals. We can talk about aesthetics, but whose aesthetic sense are we serving by using 'running' vs 'lambda'? All of this said, there is another approach that comes closer to something you suggested in a previous comment: Basket.add_apple.should change(@fruit, :count) We can't really support that without getting into continuations (no thank you), and even then I'm not convinced we wouldn't suffer some ugly side effects. That said, we *could* do this: 'Basket.add_apple'.should change('fruit.count') We'd have to eval both strings, which you could argue doesn't help any, but it does read more "ideally." WDYT? ---------------------------------------------------------------------- Comment By: sudara williams (sudara) Date: 2007-09-12 10:08 Message: Yikes! lambda = Ruby Sudara.should alias(:lambda) if Sudara.doesnt_like_it Got it. My hope is that you guys can read something deeper in my request. ---------------------------------------------------------------------- Comment By: Matt Aimonetti (matt_a) Date: 2007-09-12 09:20 Message: I agree with Aslak. lambda is part of the Ruby language, it's well documented and if you are a Ruby developer you surely know and understand what it does. Also, aliases are easy enough to add so it shouldn't be a big deal for you to add your own. ---------------------------------------------------------------------- Comment By: sudara williams (sudara) Date: 2007-09-12 08:39 Message: Awwww.... The only thing lambda screens in my face is "what a terribly unhelpful name!" I'll relax ;) A programmer's love for the obscure is only a variation of human love for the familiar. My point with Rspec: lambda (despite it being a familiar idiom to non-beginners) has a single use in Rspec - to specify a code block that will be run as a part of evaluating a more complex match. In other words, Rspec needs to run some code before and after this block in order to do it's magic. Long story short, my opinion Rspec asks me to hack itself using a technique that just aint readable, making for a heavy feeling. >From a DSL point of view (aka, learning Rspec) there is no real way to differentiate matchers that need it. The More Complicated Ones. Idiomatically, lambda is being used as a helper within Rspec internals. Using it, Rspec can go about wrapping my lambda with some code and then executing it. That is the idiom in place here, and that idiom is much better expressed as "running." After all, this is the DSL we'd really love to have, eh? Basket.add_apple.should change(@fruit, :count Thanks for listening, and I'll walk away from this happy to learn and without expecting um that anything.should change ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-09-11 21:40 Message: I must say I agree with Aslak, because lambda screams in my face *delayed evaluation* The reason I suggested run was that a co-worker (who is new to rspec) suggested it. He comes from Test::Unit and keeps on making this mistake: my_method.should raise_error If the code doesn't raise an error (say it returns nil) - then the error message will read something like the following: NoMethodError: nil.call ... (Obviously here the proc is trying to be called...) So maybe a better error message would work in this case? (ps: What is the internal vs. external DSL conversation?) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-09-11 18:19 Message: Based on recent conversations re: internal vs external DSL's, I have to go w/ Aslak on this one. It's important that your customers understand the Strings you pass to describe and it. It's important that your fellow programmers understand the code in the block. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-09-11 18:10 Message: -1 While I value readability, I value idioms more. lambda is at ruby's core and it's a common idiom - I don't want an alias for it, but everyone is free to make their own alias. ---------------------------------------------------------------------- Comment By: Jay Levitt (jaylev) Date: 2007-09-11 17:27 Message: "run" doesn't read as English, though... running {this}.should do_that ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-09-11 17:26 Message: How about run { do_something }.should raise_error ? ---------------------------------------------------------------------- Comment By: Jay Levitt (jaylev) Date: 2007-09-11 05:55 Message: +1!! ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13837&group_id=797 From lists-rspec at shopwatch.org Wed Sep 12 11:54:00 2007 From: lists-rspec at shopwatch.org (Jay Levitt) Date: Wed, 12 Sep 2007 11:54:00 -0400 Subject: [rspec-devel] Trac instead of Rubyforge tracker? In-Reply-To: <46E7EADA.4090203@tastapod.com> References: <46DF3ED5.7040109@gmail.com> <8d961d900709071515q415c0e71n17046c3fedb3efea@mail.gmail.com> <46E55337.20400@shopwatch.org> <46E7EADA.4090203@tastapod.com> Message-ID: <46E80B98.6090806@jay.fm> Dan North wrote: > If we're thinking about that route, I have a linux VPS on the uk > backbone (so it's highly available and has something like 1Gbit network > access, and won't get capped by Sky!). That sounds a lot better than my old PC with half a RAID array under the desk.. I'll let you take it from here :) Looks like svnsync is the answer for a read-only repository mirror, and it doesn't look very complicated. Jay From noreply at rubyforge.org Wed Sep 12 11:59:12 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 12 Sep 2007 11:59:12 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-13837 ] alias :running, :lambda Message-ID: <20070912155912.D82315240B88@rubyforge.org> Feature Requests item #13837, was opened at 2007-09-11 09:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13837&group_id=797 Category: expectation module Group: None Status: Closed Priority: 3 Submitted By: sudara williams (sudara) Assigned to: David Chelimsky (dchelimsky) Summary: alias :running, :lambda Initial Comment: For everyday Rspec "reads like english" purposes, aliasing lambda as "running" would make for some fun spec writing: running { something_risky }.should raise_error running { Fancy.operation }.should_not change(@simple, :factor) or even running { to_the_bathroom }.should_not change(person, :weight) describe "A clear spec language" do it "should replace generic lowlevel language with intuitive goodies" do running { 5.to_s }.call.should == lambda { 5.to_s }.call end end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-12 15:59 Message: class String def call eval(self) end end I think that should do it, no? ---------------------------------------------------------------------- Comment By: Jay Levitt (jaylev) Date: 2007-09-12 15:47 Message: Oo, that's pretty too. I understand that lambda is a common Ruby-ism, but at the moment, nothing I do (or expect to do in Rails) needs it -except- for rspec, and I don't like to have to think in metaprogramming mode unless I need to. If the eval method is easy to code, works the same as lambda does today, doesn't create any maintenance nightmares, etc., I'd +1 that.. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-09-12 15:37 Message: "My hope is that you guys can read something deeper in my request" strikes me as patronizing and not very helpful. If you're interested in helping us to learn something that we may be missing, please continue to do so respectfully, by example. As I see it, you would like to see RSpec read even more like English. The complicating factor is that we're really trying to ride a fine line between English and Ruby. The examples are supposed to serve as documentation at both high and low levels. At the high level, we have the strings that allow you to express things at whatever level is appropriate for the audience. If you're spec'ing a class, you can choose terminology that speaks to developers. If you're spec'ing a more high-level behaviour, something you might collaborate with customers on, you can choose domain specific terminology. At the low level, we have code. In the end, that code needs to tell its story to the developer. In fact, it has been argued that sexy little tricks like collection.should be_empty does not serve well as documentation for the developer. I believe that this argument has merit. Early on, we recognized that should_equal, while aesthetically pleasing, also hid the Ruby story, which is that there are several ways to define equality, each with their own semantics and significance. In this case we preferred Ruby over English, supporting methods that align directly to Ruby methods. In terms of lambda, this is definitely a Ruby term. No argument there. The question then becomes a matter of goals. We can talk about aesthetics, but whose aesthetic sense are we serving by using 'running' vs 'lambda'? All of this said, there is another approach that comes closer to something you suggested in a previous comment: Basket.add_apple.should change(@fruit, :count) We can't really support that without getting into continuations (no thank you), and even then I'm not convinced we wouldn't suffer some ugly side effects. That said, we *could* do this: 'Basket.add_apple'.should change('fruit.count') We'd have to eval both strings, which you could argue doesn't help any, but it does read more "ideally." WDYT? ---------------------------------------------------------------------- Comment By: sudara williams (sudara) Date: 2007-09-12 14:08 Message: Yikes! lambda = Ruby Sudara.should alias(:lambda) if Sudara.doesnt_like_it Got it. My hope is that you guys can read something deeper in my request. ---------------------------------------------------------------------- Comment By: Matt Aimonetti (matt_a) Date: 2007-09-12 13:20 Message: I agree with Aslak. lambda is part of the Ruby language, it's well documented and if you are a Ruby developer you surely know and understand what it does. Also, aliases are easy enough to add so it shouldn't be a big deal for you to add your own. ---------------------------------------------------------------------- Comment By: sudara williams (sudara) Date: 2007-09-12 12:39 Message: Awwww.... The only thing lambda screens in my face is "what a terribly unhelpful name!" I'll relax ;) A programmer's love for the obscure is only a variation of human love for the familiar. My point with Rspec: lambda (despite it being a familiar idiom to non-beginners) has a single use in Rspec - to specify a code block that will be run as a part of evaluating a more complex match. In other words, Rspec needs to run some code before and after this block in order to do it's magic. Long story short, my opinion Rspec asks me to hack itself using a technique that just aint readable, making for a heavy feeling. >From a DSL point of view (aka, learning Rspec) there is no real way to differentiate matchers that need it. The More Complicated Ones. Idiomatically, lambda is being used as a helper within Rspec internals. Using it, Rspec can go about wrapping my lambda with some code and then executing it. That is the idiom in place here, and that idiom is much better expressed as "running." After all, this is the DSL we'd really love to have, eh? Basket.add_apple.should change(@fruit, :count Thanks for listening, and I'll walk away from this happy to learn and without expecting um that anything.should change ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-09-12 01:40 Message: I must say I agree with Aslak, because lambda screams in my face *delayed evaluation* The reason I suggested run was that a co-worker (who is new to rspec) suggested it. He comes from Test::Unit and keeps on making this mistake: my_method.should raise_error If the code doesn't raise an error (say it returns nil) - then the error message will read something like the following: NoMethodError: nil.call ... (Obviously here the proc is trying to be called...) So maybe a better error message would work in this case? (ps: What is the internal vs. external DSL conversation?) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-09-11 22:19 Message: Based on recent conversations re: internal vs external DSL's, I have to go w/ Aslak on this one. It's important that your customers understand the Strings you pass to describe and it. It's important that your fellow programmers understand the code in the block. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-09-11 22:10 Message: -1 While I value readability, I value idioms more. lambda is at ruby's core and it's a common idiom - I don't want an alias for it, but everyone is free to make their own alias. ---------------------------------------------------------------------- Comment By: Jay Levitt (jaylev) Date: 2007-09-11 21:27 Message: "run" doesn't read as English, though... running {this}.should do_that ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-09-11 21:26 Message: How about run { do_something }.should raise_error ? ---------------------------------------------------------------------- Comment By: Jay Levitt (jaylev) Date: 2007-09-11 09:55 Message: +1!! ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13837&group_id=797 From noreply at rubyforge.org Wed Sep 12 15:42:17 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 12 Sep 2007 15:42:17 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-13879 ] "P" for pending looks too much like "F" for failure -- please put back "*" Message-ID: <20070912194217.511115240C9D@rubyforge.org> Bugs item #13879, was opened at 2007-09-12 12:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13879&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Alex Chaffee (alexch) Assigned to: Nobody (None) Summary: "P" for pending looks too much like "F" for failure -- please put back "*" Initial Comment: We love pending! But we hate "P". From across the room, or for eyes over 40 years old, it looks like our test run just broke when actually it's just a pending test. Why did you change it from "*"? We like "*". It even means "footnote" or "see below for more information" which is actually pretty appropriate for a pending example... ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13879&group_id=797 From noreply at rubyforge.org Wed Sep 12 17:22:11 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 12 Sep 2007 17:22:11 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-13881 ] Dynamically include Helpers that are included on ActionView::Base Message-ID: <20070912212211.7F30B5240E9B@rubyforge.org> Patches item #13881, was opened at 2007-09-12 17:22 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13881&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brandon Keepers (brandon) Assigned to: Nobody (None) Summary: Dynamically include Helpers that are included on ActionView::Base Initial Comment: It seems there's been several times lately where edge Rails removes a module, which breaks rspec. This has been updated in rspec's trunk, but puts those that want to use released versions of rspec with edge rails in a bit of a pickle. This patch will simply include all of the helper modules that are included in ActionView::Base. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13881&group_id=797 From noreply at rubyforge.org Wed Sep 12 17:30:28 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 12 Sep 2007 17:30:28 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-13881 ] Dynamically include Helpers that are included on ActionView::Base Message-ID: <20070912213028.64DB05240EB1@rubyforge.org> Patches item #13881, was opened at 2007-09-12 21:22 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13881&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Brandon Keepers (brandon) >Assigned to: David Chelimsky (dchelimsky) Summary: Dynamically include Helpers that are included on ActionView::Base Initial Comment: It seems there's been several times lately where edge Rails removes a module, which breaks rspec. This has been updated in rspec's trunk, but puts those that want to use released versions of rspec with edge rails in a bit of a pickle. This patch will simply include all of the helper modules that are included in ActionView::Base. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-12 21:30 Message: F(*&^(*ing brilliant! Thanks - can't do this right now but I will in an hour or two. Cheers, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13881&group_id=797 From michael.s.klishin.lists at gmail.com Wed Sep 12 17:39:18 2007 From: michael.s.klishin.lists at gmail.com (Michael Klishin) Date: Thu, 13 Sep 2007 01:39:18 +0400 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: That helps a lot, thanks David. On 10/09/2007, 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. -- MK From noreply at rubyforge.org Wed Sep 12 19:30:45 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 12 Sep 2007 19:30:45 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-6397 ] Support headers and session variables in http requests Message-ID: <20070912233045.C767F5240CE9@rubyforge.org> Feature Requests item #6397, was opened at 2006-10-30 08:17 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6397&group_id=797 Category: rails plugin Group: None Status: Open Priority: 3 Submitted By: Jeff Dean (jefdean) Assigned to: Nobody (None) Summary: Support headers and session variables in http requests Initial Comment: [the following is a duplicate comment from one I posted on the mailing list because rubyforge logins were down for a while...] I'd love to see better support for specifying headers headers and session variables to the http requests - something like: _verb_(action, parameters=nil, session_vars=nil, headers=nil) This way we could write: get(:index, {:id=>1}, {:user=>@user}, {:accept=>'application/...'}) Or add some syntactic sugar such as: get(:index, {}, {}, {:format=>:js}) to simulate xml/javascript/mobile device formats. I'll start working on this shortly unless anyone else has the time to do it easily and quickly. ---------------------------------------------------------------------- Comment By: Assaf Arkin (assaf) Date: 2007-09-12 23:30 Message: Sessions and headers would be a nice addition. In controller specs, get/post/etc bypass CgiRequest which handles headers and content decoding, so if you want to specify the format, pass :format=>'json' as a parameter, not header. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-14 15:16 Message: Noone has been working on it. Feel free to contribute a patch. Since I last commented on this issue RSpec no longer depends on zentest. ---------------------------------------------------------------------- Comment By: Douglas Tan (bianster) Date: 2007-05-14 14:45 Message: Has any progress been made regarding this? I'll like to help with implementing the feature. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2006-10-31 00:24 Message: I don't think anyone is working on it. Make sure you submit specs too :-) I haven't looked into the details, but you might actually have to patch zentest, since rspec on rails builds on it. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6397&group_id=797 From noreply at rubyforge.org Wed Sep 12 19:50:35 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 12 Sep 2007 19:50:35 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-6059 ] Controller testing w/ Rails: response is not upated when same action is GETted multiple times within a specify block Message-ID: <20070912235035.D7C3F5240EBA@rubyforge.org> Feature Requests item #6059, was opened at 2006-10-08 01:54 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6059&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: David Lee (davidlee) Assigned to: Nobody (None) Summary: Controller testing w/ Rails: response is not upated when same action is GETted multiple times within a specify block Initial Comment: Controller testing with RSpec + Rails: response is not upated within a specification when same action is called multiple times within a specify block using Rails 1.1.6 and RSpec 0.6.4 The response object is not being updated within a specify block if multiple responses are generated by GETting the same action. This was verified by checking the redirect_url reported. This does not appear to be an issue unless the *same action* is called multiple times within a specify block, eg to test the effect of accessing an action with different permissions or parameters. Calling the action with different parameters did not appear to affect the problem. example: specify "Index should redirect to welcome if already logged in" do # this will redirect to login as user is not logged in. # the presence of this line will break the test. get :index request.session[:user] = 1 # subsequent gets will redirect to welcome # this will be ignored with regard to the response.redirect_url reported get :index response.should_redirect # fails if first line is present: # says the redirect_url equals 'http://test.host/account/login' # which is a leftover from the first get :index response.redirect_url.should_equal 'http://test.host/account/welcome' end breaking the two `get :index` calls out into separate specify blocks alleviates the problem. ---------------------------------------------------------------------- Comment By: Assaf Arkin (assaf) Date: 2007-09-12 23:50 Message: Given GET request returning Last-Modified When GET request uses it as If-Unmodified-Since Then 304 (Not Modified) But due to this design, I'm going to receive 200 the second time. Note that I don't care to mock the value of Last-Modified, this is the expected behavior of the controller. Or: Given PUT entity in resource When GET entity from resource Then 200 (OK) and entities are equivalent But if PUT returns 201 (Created), then so will GET. Again, I do not care to mock the model, it's too much work to get the model to match the output, when neither mock nor model are the behavior I'm testing here. I think controller specs that can only issue one request are too fine grained. It's the equivalent of model specs where you can create or find or update, but not do both in a single sequence. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-07 11:02 Message: Also - moving this over to feature requests - this is by design, not a bug. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2006-11-07 11:02 Message: "breaking the two `get :index` calls out into separate specify blocks alleviates the problem." That's also the BDD way. Given (context) When (single event or set of events) Then (outcomes) The specs could read: Given a user who is logged in - GET index should redirect to welcome Given a user who is NOT logged in - GET index should redirect to login page OR you could have two specs in the same context: GET index - should redirect a logged in user to welcome - should redirect an anonymous user to the login page We will need to support multiple GETS when we add integration specs, so I'll leave this open to keep it on the radar, but we will likely not be supporting this in the context of controller specs. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6059&group_id=797 From noreply at rubyforge.org Wed Sep 12 20:06:38 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 12 Sep 2007 20:06:38 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-13487 ] Parameterize Shared Behaviours Message-ID: <20070913000638.928185240D08@rubyforge.org> Feature Requests item #13487, was opened at 2007-08-29 13:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13487&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: David Chelimsky (dchelimsky) Assigned to: Nobody (None) Summary: Parameterize Shared Behaviours Initial Comment: There has been discussion of parameterized shared behaviours, but t The current implementation of shared behaviours copies examples into the execution scope of the including behaviour. This gives the examples access to state defined in before(:each) in the including example. This works well, but does some a bit like black magic: describe "a RESTful controller", :shared => true do it "should find all instances of the resource" do @model_class.should_receive(:find).with(:all) get 'index' end end describe FooController do before(:each) do @model_class = Foo end it_should_behave_like "a RESTful controller" end The steps in the new Story Runner (Given, When, Then) all take arguments, supporting reusable blocks. We should do the same thing with shared behaviours. I think that parameterizing these would be a cleaner solution, but I think it would require a separate construct (internally) than the one we have - if parameterized it should not share state with the including behaviour. But I can imagine something like this: #DOES NOT EXIST YET describe "a RESTful controller" do |model_class| it "should find all instances of the resource" do model_class.should_receive(:find).with(:all) get 'index' end end describe FooController do #DOES NOT EXIST YET it_should_behave_like "a RESTful controller", Foo end We might not even need the :shared => true flag if the describe block has block args - arity > 0 could be the indicator to share. Now this approach has it's drawbacks as well. If you end up w/ a long list of block args, you'd best get them in the right order. Sharing instance variables is its own brand of voodoo, but at least you can name them well. I guess we could add a hash: it_should_behave_like "a RESTful controller", :model_class => Foo But that starts to get ugly pretty quickly as well. Thoughts? ---------------------------------------------------------------------- Comment By: Assaf Arkin (assaf) Date: 2007-09-13 00:06 Message: I would prefer to get rid of :shared=>true by adding a new method, say shared instead of describe. It's easier to scan through the code and identity the shared behaviors. Arity would make sense when I'm writing a shared behavior, but much harder to spot them when I'm reading the code. And another +1 to parameterizing shared behaviors. Right now I handle that by defining a method for use by the shared behavior assumes exist, so: describe "using shared" do it_should_behave_like "a RESTful controller" define_method(:model_class) { Foo } end This can be done with hashes (create methods to hold those values), or named arguments, but unfortunately not both. ---------------------------------------------------------------------- Comment By: Tom Stuart (tstuart) Date: 2007-08-30 07:33 Message: David: in the vaguely-analogous case of Rails partials, controller state is shared (i.e. access to the instance variables still works) even when the partial is parameterised (i.e. render :partial => ..., :locals => { ... }), so the combination of both in shared behaviours may feel familiar to Rails users at least. ---------------------------------------------------------------------- Comment By: Dan North (tastapod) Date: 2007-08-29 23:27 Message: I'm missing something here. Can't all this shared behaviour just be achieved using mixins? module BehavesLikeARestfulController # expects @model_class to be defined it "should find all instances of the resource" do @model_class.should_receive(:find).with(:all) get 'index' end end describe FooController do @model_class = Foo include BehavesLikeARestfulController end The example runner will re-initialise @model_class for each example (it-block) in the mixin because each one runs in a separate object instance. Also, you can put before(:each) code in the module to make it self-contained, and the runner should Do The Right Thing (i.e. add it to any additional before(:each) in the specific describe block). How does this help me? I wasn't around for the original conversations that led to :shared behaviours in the first place, so apologies if I'm going over old ground. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-08-29 20:18 Message: I was thinking it should either be shared state or parameterized, but not both. That strikes me as the least confusing option. But I'm convincable. ---------------------------------------------------------------------- Comment By: Ian Dees (undees) Date: 2007-08-29 19:22 Message: +1 on letting the describe block's arity indicate shared-itude. >From there, the test author can choose whether to put a few block parameters in a row or use a single hash parameter. If this gets implemented, are you going to revoke shared behaviors' access to the state of the describe block where they're used? I could see this causing confusion. After all, shared Given/When/Then blocks definitely have access to their Scenario's state. ---------------------------------------------------------------------- Comment By: Tom Stuart (tstuart) Date: 2007-08-29 14:44 Message: This functionality would presumably be used in the presence of inheritance (or mixins etc) in the code being specified, so it'd be nice to support something that behaves like spec inheritance, e.g. the ability to extend or override individual shared behaviors, but it's hard to see how that could work. It's certainly easier to demand that shared behaviors be kept fine-grained enough to be mixed-and-matched as required. ---------------------------------------------------------------------- Comment By: Tom Stuart (tstuart) Date: 2007-08-29 14:35 Message: Using a hash looks ugly but arguably is more natural and provides maximum flexibility, particularly in a situation where one has a healthy set of default options and wants to tweak individual values as necessary: describe FooController do it_should_behave_like "a RESTful controller", options.merge { :model_class => Foo } end Of course, if you do it with block args then this is already available to the user as a special case! The idea of getting rid of :shared => true in the presence of describe block args is really cool. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13487&group_id=797 From noreply at rubyforge.org Wed Sep 12 20:11:39 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 12 Sep 2007 20:11:39 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-13885 ] be_status methods Message-ID: <20070913001139.873735240EC1@rubyforge.org> Feature Requests item #13885, was opened at 2007-09-13 00:11 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13885&group_id=797 Category: rails plugin Group: None Status: Open Priority: 3 Submitted By: Assaf Arkin (assaf) Assigned to: Nobody (None) Summary: be_status methods Initial Comment: response.should be_successful or response.should be_missing are nice but not enough. In too many cases I'm looking for response codes that are neither 200 nor 404. So how about adding all the status symbols as tests methods? Controller: head :unauthorized Spec: response.should be_unauthorized Controller: head :gone Spec: response.should be_gone And so forth. This code will do it for anything using controller (TestResponse) and integration (CgiResponse) tests: module ActionController # TestResponse for functional, CgiResponse for integration. class AbstractResponse StatusCodes::SYMBOL_TO_STATUS_CODE.each do |symbol, code| define_method("#{symbol}?") { self.response_code == code } unless instance_methods.include?("#{symbol}?") end end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13885&group_id=797 From noreply at rubyforge.org Thu Sep 13 02:05:45 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 13 Sep 2007 02:05:45 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-13881 ] Dynamically include Helpers that are included on ActionView::Base Message-ID: <20070913060545.D76445240F19@rubyforge.org> Patches item #13881, was opened at 2007-09-12 21:22 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13881&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Brandon Keepers (brandon) Assigned to: David Chelimsky (dchelimsky) Summary: Dynamically include Helpers that are included on ActionView::Base Initial Comment: It seems there's been several times lately where edge Rails removes a module, which breaks rspec. This has been updated in rspec's trunk, but puts those that want to use released versions of rspec with edge rails in a bit of a pickle. This patch will simply include all of the helper modules that are included in ActionView::Base. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-13 06:05 Message: Applied to r2562. Thanks for solving this properly. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-09-12 21:30 Message: F(*&^(*ing brilliant! Thanks - can't do this right now but I will in an hour or two. Cheers, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13881&group_id=797 From noreply at rubyforge.org Thu Sep 13 02:06:54 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 13 Sep 2007 02:06:54 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-13814 ] RSpec on Rails w/ fixture-scenarios Message-ID: <20070913060654.D87CD5240F08@rubyforge.org> Patches item #13814, was opened at 2007-09-10 06: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: Closed >Resolution: Accepted 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 ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-13 06:06 Message: Applied to r2558. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13814&group_id=797 From noreply at rubyforge.org Thu Sep 13 02:10:22 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 13 Sep 2007 02:10:22 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-13717 ] typo in docs Message-ID: <20070913061022.D68655240F08@rubyforge.org> Patches item #13717, was opened at 2007-09-06 18: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: Closed >Resolution: Accepted 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 ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-13 06:10 Message: You didn't upload a patch, but I fixed the typo in r2563. Next time be sure to check the checkbox before you upload a file :) ---------------------------------------------------------------------- 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 13 02:14:04 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 13 Sep 2007 02:14:04 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-11254 ] RSpec syntax coloring and function pop-up integration in TextMate Message-ID: <20070913061404.C4A645240F11@rubyforge.org> Patches item #11254, was opened at 2007-05-31 14:43 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11254&group_id=797 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Wincent Colaiuta (wincent) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: RSpec syntax coloring and function pop-up integration in TextMate Initial Comment: This patch makes two additions to the RSpec TextMate bundle to provide a better user experience: syntax coloring of RSpec keywords (before, after, describe, it), and display of behaviours and examples in the function pop-up menu. This latter feature is very useful for navigation when working with files with large numbers of specs. Examples appear indented. Now, this is my first ever TextMate customization so I am sure someone more experienced could improve on the implementation, but in its basic form it works. Shortcomings of the current implementation: - recognition occurs at the whole-line level, so syntax colouring only kicks in once you have typed the entire line - recognition simplisticly divides the behaviour and example descriptions into three parts, the "describe" (or "it"), the "do", and "everything else" between the two - this in turn means that there is no special syntax colouring of the "everything else" - it also means that examples such as: it "should be valid" do ... end will appear in the function pop-up with the enclosing quotes: "should be valid" - likewise, a behaviour like: describe User, "at creation time" do ... end Will appear in the function pop-up as: User, "at creation time" - and shared behaviours will appear as: "All controllers", :shared => true Hopefully someone with more knowledge about TextMate customization than I can address these issues, but as it stands I think the basic implementation is useful enough that life is better with the aid of these imperfect changes. Will also try to attach a screenshot with the patch to show what the pop-up looks like. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-13 06:14 Message: This got applied a few commits back (r2387). Thanks! ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-07-16 11:06 Message: Tried to include this comment when I attached the patch, but RubyForge logged me out (accepting the upload but rejecting the comment! darn transparent proxy...); so here it is again: Ok, Allan responded to the ticket. I'm going to attach an updated patch which uses "spec.rb" as the file extension instead of "_spec.rb". Also, Allan notes that if you have previously (implicitly) told TextMate to open ".rb" files as Ruby, you'll need to undo that in one of these ways: 1. Open a test.rb file and then switch away from Ruby and back again ? then TM notices that you?re selecting the default language, and will remove the explicit binding for ?.rb? files (ensure though that only the Ruby bundle has ?rb? declared as an extension). 2. defaults delete com.macromates.textmate OakLanguageFileBindings ? this deletes all stored bindings. ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-07-08 10:48 Message: Posted a follow-up TextMate ticket here: http://macromates.com/ticket/show?ticket_id=0F597093 ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-07-08 10:27 Message: Just attached an updated patch with "_spec.rb" denoted as file extension. ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-07-08 10:14 Message: Awesome, looks like the requested change is already implemented in the new r1405: [NEW] Add ?_? to the set of anchor characters for file types (extensions) -- ticket 48BF377 ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-07-07 18:51 Message: Ok, submitted a TextMate feature request here: http://macromates.com/ticket/show?ticket_id=48BF3775 ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-07-07 18:46 Message: Very interesting... Noticed in the changelog for the just released TextMate r1401 the following: [CHANGED] File types (extensions) specified in language grammars are now matched against the full path so e.g. ?.git/config? and ?.ssh/config? are both valid extensions -- the match is required to be anchored either at an ?/? or ?.? so e.g. ?tml? will not match ?index.html?. On a tie, the longest suffix-match is chosen. So, not quite what would be necessary to distinguish between ".rb" and "_spec.rb", but a step closer. Think I might file a TextMate feature request to accept "_" as an anchor as well; that would allow spec files to be auto-detected and auto-syntax highlighted. ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-06-25 09:21 Message: (1) The patch was made against the trunk back at the end of May (r2060, I think). The changes to the info.plist (shouldn't it be Info.plist, btw?) weren't manually done by me, but were inserted by TextMate when I made the other additions via its Bundle Editor. These settings are pretty opaque to me and omitting them seems to make no difference, so I will attach a patch against the current trunk which does not include the info.plist changes. (2) There aren't any new user-settable "preferences" as such. The two new files in the "Preferences" subdirectory of the bundle are used to add Behaviours and Examples to the TextMate symbols list... this is what allows them to appear in the pop-up. (3) To see the syntax highlighting you must select "RSpec" from the language pop-up at the bottom of the window. This is just like when you have a Rails file and want special Rails-specific highlighting instead of the default Ruby highlighting. It would be nice if TextMate allowed you to specify that all files ending in "_spec.rb" would be auto-detected as RSpec files, but as far as I know, TextMate only allows you to specify the extension part (".rb") and that would override the default Ruby highlighting. So if we want that feature we either need to try again get the RSpec syntax rolled into the Ruby.tmbundle, or try to get Allan to modify Textmate to allow us to specify not just the extension. (4) The pop-up menu is the function pop-up at the bottom of the TextMate window (right hand side). I don't know if there is a keyboard shortcut; I use the mouse for that. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-06-24 13:06 Message: This sounds great, but I'm having some problems. 1) The patch doesn't apply cleanly against trunk r2121 with "patch -p0 < textmate.diff": patching file Preferences/Symbol patching file Preferences/Symbol patching file info.plist Hunk #1 FAILED at 280. 1 out of 1 hunk FAILED -- saving rejects to file info.plist.rej patching file Syntaxes/RSpec.tmLanguage $ cat info.plist.rej *************** *** 280,285 **** 240FDD9D-CD49-4917-9003-80A3E1DADFBA B5906021-8E54-4863-A13B-EA46333DB5F1 67E726E0-63E2-4840-B8BB-37F665CD34B8 uuid 4CEA47CC-2C3A-45FB-80BE-3820828227C2 --- 280,288 ---- 240FDD9D-CD49-4917-9003-80A3E1DADFBA B5906021-8E54-4863-A13B-EA46333DB5F1 67E726E0-63E2-4840-B8BB-37F665CD34B8 + 923F0A10-96B9-4792-99A4-94FEF66E0B8C + 57EF6130-05A6-4117-94CB-C0BD63328334 + 28F89786-04F4-43D7-82A6-34B046C2BC6B uuid 4CEA47CC-2C3A-45FB-80BE-3820828227C2 2) I tried to add the three rejected lines manually, and in the bundle editor I can see the new RSpec syntax, but I don't see the new preferences. Shouldn't they show up too? 3) There is no new syntax highlighting on my Textmate. How does TextMate know to use this highlighting? Do I need to do anything special to make it work? 4) How do I bring up the list over behaviours and examples shown in your screenshot? It must be some keyboard shortcut I'm unaware of. Cheers, Aslak ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11254&group_id=797 From noreply at rubyforge.org Thu Sep 13 02:16:24 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 13 Sep 2007 02:16:24 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-13759 ] rails_rspec overwrites test mappings added in .autotest Message-ID: <20070913061625.036D95240F08@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. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-13 06:16 Message: Please post your .autotest file so I can see this in action. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13759&group_id=797 From noreply at rubyforge.org Thu Sep 13 02:42:04 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 13 Sep 2007 02:42:04 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-13708 ] Revision 2482 killed custom assertions in spec:ui Message-ID: <20070913064204.BD1B75240F08@rubyforge.org> Bugs item #13708, was opened at 2007-09-06 08: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: David Chelimsky (dchelimsky) Date: 2007-09-13 06:42 Message: Ah yes - this was a fix to another RFE that wanted the rspec matchers available everywhere under spec. Need to think about how I want to approach this. Probably undo the other feature so you get rails goodies for free in spec/models, spec/views, spec/controllers, spec/helpers, and spec/lib, but anywhere else you have explicitly say :behaviour_type => :rails. WDYT? ---------------------------------------------------------------------- Comment By: Marcus Ahnve (mahnve) Date: 2007-09-06 08: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 13 07:26:08 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 13 Sep 2007 07:26:08 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-13837 ] alias :running, :lambda Message-ID: <20070913112609.80CE05240988@rubyforge.org> Feature Requests item #13837, was opened at 2007-09-11 09:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13837&group_id=797 Category: expectation module Group: None Status: Closed Priority: 3 Submitted By: sudara williams (sudara) Assigned to: David Chelimsky (dchelimsky) Summary: alias :running, :lambda Initial Comment: For everyday Rspec "reads like english" purposes, aliasing lambda as "running" would make for some fun spec writing: running { something_risky }.should raise_error running { Fancy.operation }.should_not change(@simple, :factor) or even running { to_the_bathroom }.should_not change(person, :weight) describe "A clear spec language" do it "should replace generic lowlevel language with intuitive goodies" do running { 5.to_s }.call.should == lambda { 5.to_s }.call end end ---------------------------------------------------------------------- >Comment By: sudara williams (sudara) Date: 2007-09-13 11:26 Message: Double Fuggles! No patronizing is in my heart. "Read something deeper, please" is a simple response to the "It is ruby, alias it yourself," which avoids the real discussion and 95% of what I desire to communicate. The string solution is interesting. How about this: The core reason for the usage of lambda (forcing a different pattern for some Rspec matchers, a confusing metaprogamming trick for noobees, and a break from readability) seems to be the need to run code before and after the code specified in the "it" block. In the case of raise_error, we need to catch exceptions. In the case of should change, we need to grab a value before and after, and then compare those two. How about refactoring the pattern from "User uses lambda and a special matcher. Matcher executes code, calls lambda, executes code, evaluates" to "If the matcher requires before and after code, we callback for it before and after running the matcher" The benefits would be good - improved consistency and dsl, and it would also open up matchers to be more flexible. That being said, I've stared at the Spec::DSL stuff for the last 30 min and don't find myself smart enough to really see how that would work. Maybe it can't. What do you think? Anywho, I'm 150% fine with moving on and accepting the current dsl, I just wanted to voice my suggestion- an opportunity for improvement. I've kicked in maybe 50 hours with Rspec so far, and though it was slow going at the start, I really really really really really like the attitudes and processes that you guys are promoting. I've grown a lot as a developer because of it. Thank you, su ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-09-12 15:59 Message: class String def call eval(self) end end I think that should do it, no? ---------------------------------------------------------------------- Comment By: Jay Levitt (jaylev) Date: 2007-09-12 15:47 Message: Oo, that's pretty too. I understand that lambda is a common Ruby-ism, but at the moment, nothing I do (or expect to do in Rails) needs it -except- for rspec, and I don't like to have to think in metaprogramming mode unless I need to. If the eval method is easy to code, works the same as lambda does today, doesn't create any maintenance nightmares, etc., I'd +1 that.. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-09-12 15:37 Message: "My hope is that you guys can read something deeper in my request" strikes me as patronizing and not very helpful. If you're interested in helping us to learn something that we may be missing, please continue to do so respectfully, by example. As I see it, you would like to see RSpec read even more like English. The complicating factor is that we're really trying to ride a fine line between English and Ruby. The examples are supposed to serve as documentation at both high and low levels. At the high level, we have the strings that allow you to express things at whatever level is appropriate for the audience. If you're spec'ing a class, you can choose terminology that speaks to developers. If you're spec'ing a more high-level behaviour, something you might collaborate with customers on, you can choose domain specific terminology. At the low level, we have code. In the end, that code needs to tell its story to the developer. In fact, it has been argued that sexy little tricks like collection.should be_empty does not serve well as documentation for the developer. I believe that this argument has merit. Early on, we recognized that should_equal, while aesthetically pleasing, also hid the Ruby story, which is that there are several ways to define equality, each with their own semantics and significance. In this case we preferred Ruby over English, supporting methods that align directly to Ruby methods. In terms of lambda, this is definitely a Ruby term. No argument there. The question then becomes a matter of goals. We can talk about aesthetics, but whose aesthetic sense are we serving by using 'running' vs 'lambda'? All of this said, there is another approach that comes closer to something you suggested in a previous comment: Basket.add_apple.should change(@fruit, :count) We can't really support that without getting into continuations (no thank you), and even then I'm not convinced we wouldn't suffer some ugly side effects. That said, we *could* do this: 'Basket.add_apple'.should change('fruit.count') We'd have to eval both strings, which you could argue doesn't help any, but it does read more "ideally." WDYT? ---------------------------------------------------------------------- Comment By: sudara williams (sudara) Date: 2007-09-12 14:08 Message: Yikes! lambda = Ruby Sudara.should alias(:lambda) if Sudara.doesnt_like_it Got it. My hope is that you guys can read something deeper in my request. ---------------------------------------------------------------------- Comment By: Matt Aimonetti (matt_a) Date: 2007-09-12 13:20 Message: I agree with Aslak. lambda is part of the Ruby language, it's well documented and if you are a Ruby developer you surely know and understand what it does. Also, aliases are easy enough to add so it shouldn't be a big deal for you to add your own. ---------------------------------------------------------------------- Comment By: sudara williams (sudara) Date: 2007-09-12 12:39 Message: Awwww.... The only thing lambda screens in my face is "what a terribly unhelpful name!" I'll relax ;) A programmer's love for the obscure is only a variation of human love for the familiar. My point with Rspec: lambda (despite it being a familiar idiom to non-beginners) has a single use in Rspec - to specify a code block that will be run as a part of evaluating a more complex match. In other words, Rspec needs to run some code before and after this block in order to do it's magic. Long story short, my opinion Rspec asks me to hack itself using a technique that just aint readable, making for a heavy feeling. >From a DSL point of view (aka, learning Rspec) there is no real way to differentiate matchers that need it. The More Complicated Ones. Idiomatically, lambda is being used as a helper within Rspec internals. Using it, Rspec can go about wrapping my lambda with some code and then executing it. That is the idiom in place here, and that idiom is much better expressed as "running." After all, this is the DSL we'd really love to have, eh? Basket.add_apple.should change(@fruit, :count Thanks for listening, and I'll walk away from this happy to learn and without expecting um that anything.should change ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-09-12 01:40 Message: I must say I agree with Aslak, because lambda screams in my face *delayed evaluation* The reason I suggested run was that a co-worker (who is new to rspec) suggested it. He comes from Test::Unit and keeps on making this mistake: my_method.should raise_error If the code doesn't raise an error (say it returns nil) - then the error message will read something like the following: NoMethodError: nil.call ... (Obviously here the proc is trying to be called...) So maybe a better error message would work in this case? (ps: What is the internal vs. external DSL conversation?) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-09-11 22:19 Message: Based on recent conversations re: internal vs external DSL's, I have to go w/ Aslak on this one. It's important that your customers understand the Strings you pass to describe and it. It's important that your fellow programmers understand the code in the block. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-09-11 22:10 Message: -1 While I value readability, I value idioms more. lambda is at ruby's core and it's a common idiom - I don't want an alias for it, but everyone is free to make their own alias. ---------------------------------------------------------------------- Comment By: Jay Levitt (jaylev) Date: 2007-09-11 21:27 Message: "run" doesn't read as English, though... running {this}.should do_that ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-09-11 21:26 Message: How about run { do_something }.should raise_error ? ---------------------------------------------------------------------- Comment By: Jay Levitt (jaylev) Date: 2007-09-11 09:55 Message: +1!! ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13837&group_id=797 From noreply at rubyforge.org Thu Sep 13 11:16:31 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 13 Sep 2007 11:16:31 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-13708 ] Revision 2482 killed custom assertions in spec:ui Message-ID: <20070913151633.5115F5240B0C@rubyforge.org> Bugs item #13708, was opened at 2007-09-06 04:16 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13708&group_id=797 Category: None Group: None Status: Open >Resolution: Accepted Priority: 3 Submitted By: Marcus Ahnve (mahnve) >Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Revision 2482 killed custom assertions in spec:ui Initial Comment: Rev 2482 did something that takes our custom expectations for Selenium using spec:ui out of the call chain - they are no longer called at all. In revision 2481 this works. I've tried running the Watir examples, which custom expectations we basically copied, and they seem broken too. I am trying to locate what in that rev that causes this to happen, but I have so far been unsuccessful. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-09-13 02:42 Message: Ah yes - this was a fix to another RFE that wanted the rspec matchers available everywhere under spec. Need to think about how I want to approach this. Probably undo the other feature so you get rails goodies for free in spec/models, spec/views, spec/controllers, spec/helpers, and spec/lib, but anywhere else you have explicitly say :behaviour_type => :rails. WDYT? ---------------------------------------------------------------------- Comment By: Marcus Ahnve (mahnve) Date: 2007-09-06 04:39 Message: I found the line causing this to happen: In rspec_on_rails/lib/spec/rails/dsl/behaviour/rails_example.rb, the line Spec::DSL::BehaviourFactory.add_behaviour_class(:default, self) does something that reoverrides our custom expectations. The problem seems to be that the rspec_on_rails expectations by the call above are defined after our custom definitions. It therefore only affects our own "have_tag" etc, which have a expectation with the same name in RSpec On Rails. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13708&group_id=797 From noreply at rubyforge.org Thu Sep 13 16:34:07 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 13 Sep 2007 16:34:07 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-13907 ] Would like "exist" to be in Spec::Matchers (like the others) Message-ID: <20070913203407.AFC6C5240F37@rubyforge.org> Patches item #13907, was opened at 2007-09-13 15:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13907&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Bret Pettichord (bret) Assigned to: Nobody (None) Summary: Would like "exist" to be in Spec::Matchers (like the others) Initial Comment: I had submitted a patch http://rubyforge.org/tracker/?func=detail&group_id=797&aid=10473&atid=3152, but it was refactored in a way that reduced its scope. Specifically, I would like "should exist" to work in any class that includes Spec::Matchers, not just the it-blocks. Attached please find an additional test that fails with the current version of Rspec (as well as prior versions), but passes with my originally submitted implementation of "exist". For convenience, i have included that implementation in this test, so that the test actually passes if you apply the patch. To reproduced the failure, you'll have to remove this added class. The right solution is probably more complicated, but i never quite understood how my original solution was refactored, so i'm not sure what the best solution would be. Thank you for your consideration. With Watir, we regularly extract test code out of the specs, and therefore this ability is valuable to us. We have not seen this problem with the other methods in Spec::Matchers. Bret Index: C:/work/rspec-rspec/spec/spec/matchers/exist_spec.rb =================================================================== --- C:/work/rspec-rspec/spec/spec/matchers/exist_spec.rb (revision 2561) +++ C:/work/rspec-rspec/spec/spec/matchers/exist_spec.rb (working copy) @@ -45,4 +45,47 @@ should fail end end + +# Additional Test +module Spec + module Matchers + class Exist + def matches? actual + @actual = actual + @actual.exist? + end + def failure_message + "expected #{@actual.inspect} to exist, but it doesn't." + end + def negative_failure_message + "expected #{@actual.inspect} to not exist, but it does." + end + end + def exist; Exist.new; end + end +end + +class SubstanceTester + include Spec::Matchers + def initialize substance + @substance = substance + end + def assert_exists + @substance.should exist + end +end + +describe "should exist, outside of a behavior" do + before(:each) do + @real = Substance.new true, 'something real' + @imaginary = Substance.new false, 'something imaginary' + end + it "should still pass if target exists" do + real_tester = SubstanceTester.new @real + real_tester.assert_exists + end +end + + + ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13907&group_id=797 From dan at tastapod.com Thu Sep 13 17:42:59 2007 From: dan at tastapod.com (Dan North) Date: Thu, 13 Sep 2007 22:42:59 +0100 Subject: [rspec-devel] Trac instead of Rubyforge tracker? In-Reply-To: <57c63afe0709120838i535ca38bt3cb0a1bf5715ecce@mail.gmail.com> References: <46DF3ED5.7040109@gmail.com> <8d961d900709071515q415c0e71n17046c3fedb3efea@mail.gmail.com> <46E55337.20400@shopwatch.org> <46E7E9F5.9090807@tastapod.com> <57c63afe0709120838i535ca38bt3cb0a1bf5715ecce@mail.gmail.com> Message-ID: <46E9AEE3.8030306@tastapod.com> Something for the BDD (beer-driven development) todo list at RailsConf? David Chelimsky wrote: > On 9/12/07, Dan North wrote: > >> If we're thinking about that route, I have a linux VPS on the uk backbone >> (so it's highly available and has something like 1Gbit network access, and >> won't get capped by Sky!). >> >> I'm happy to host subversion and trac there. We can use tailor to pull down >> the repository and all its history, which is a pretty straightforward >> operation. >> >> Let me know - I'm in Linux sysadmin mode at the moment anyway, so it >> wouldn't be a very big chore. (We could host the rspec.org domain off it >> too, if any of you guys own that?). >> > > rspec.org is taken. I think it's been so for a while. I've emailed the > guy to see if he's interested in letting it go. > > As for tools, I've found trac to be a bit bloated. I'd like to look at > warehouse/lighthouse. > > Cheers, > David > > > > >> Cheers, >> Dan >> >> >> >> Jay Levitt wrote: >> 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 >> >> >> _______________________________________________ >> rspec-devel mailing list >> rspec-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-devel >> >> >> >> _______________________________________________ >> rspec-devel mailing list >> rspec-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-devel >> >> > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070913/95f73859/attachment-0001.html From noreply at rubyforge.org Thu Sep 13 19:40:45 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 13 Sep 2007 19:40:45 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-13879 ] "P" for pending looks too much like "F" for failure -- please put back "*" Message-ID: <20070913234045.22ADA5240F3E@rubyforge.org> Bugs item #13879, was opened at 2007-09-12 19:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13879&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Alex Chaffee (alexch) Assigned to: Nobody (None) Summary: "P" for pending looks too much like "F" for failure -- please put back "*" Initial Comment: We love pending! But we hate "P". From across the room, or for eyes over 40 years old, it looks like our test run just broke when actually it's just a pending test. Why did you change it from "*"? We like "*". It even means "footnote" or "see below for more information" which is actually pretty appropriate for a pending example... ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-09-13 23:40 Message: Don't you run with --color? I'm sure that would be even easier on the eyes. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13879&group_id=797 From noreply at rubyforge.org Thu Sep 13 19:49:47 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 13 Sep 2007 19:49:47 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-13913 ] Scenario should treat no code block as "pending" Message-ID: <20070913234947.EF5565240F3F@rubyforge.org> Feature Requests item #13913, was opened at 2007-09-13 19:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13913&group_id=797 Category: Story Runner Group: None Status: Open Priority: 3 Submitted By: Evan Light (sleight42) Assigned to: Nobody (None) Summary: Scenario should treat no code block as "pending" Initial Comment: Currently, Scenario errors out when not supplied a body. It should behave similarly to "describe/it" where "it" is not required to have a code block. When a code block is not given, it is treated as pending. This could also be extended to Given/Then/When. Ultmately, this would have the benefit of allowing one to effectively document the entire User Story without having to furnish any code -- but still allowing Story Runner to generate documentation for it. I'll see about supplying a patch this evening ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13913&group_id=797 From noreply at rubyforge.org Thu Sep 13 22:00:40 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 13 Sep 2007 22:00:40 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-13918 ] exception_from incorrectly returns a value when no Error occurs in specs Message-ID: <20070914020040.69FAC5240F47@rubyforge.org> Bugs item #13918, was opened at 2007-09-13 22:00 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13918&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Evan Light (sleight42) Assigned to: Nobody (None) Summary: exception_from incorrectly returns a value when no Error occurs in specs Initial Comment: In rspec_adapter.rb, if exception_from is invoked with a block that does not result in an Error, it will instead return the result of the called block. Patch attached. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13918&group_id=797 From evan at tiggerpalace.com Thu Sep 13 22:45:24 2007 From: evan at tiggerpalace.com (Evan David Light) Date: Thu, 13 Sep 2007 22:45:24 -0400 Subject: [rspec-devel] Howdy... and a question. Message-ID: Howdy all. Just signed up on the dev list. I've been using RSpec in anger for perhaps a total of a few days and just started playing with Story Runner. Love it. I also started working on a patch, which ought to be simple, to allow for Scenarios without supplied blocks to be treated as pending -- much like "it" in Spec::DSL::ExampleAPI. That said, I noticed something that seemed odd and chatted with Rein Henrichs a little about it on #rspec. ScenarioRunner#run treats "pending" scenarios as an error case. We both believed this to be a little odd as we both thought that pending would just be a branch and not an error. That said, I thought that there may be a reasonable explanation. Evan Light IMs (all): sleight42 http://evan.tiggerpalace.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070913/e8501abd/attachment.html From noreply at rubyforge.org Thu Sep 13 23:37:27 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 13 Sep 2007 23:37:27 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-13913 ] Scenario should treat no code block as " pending" Message-ID: <20070914033727.9FF545240B4A@rubyforge.org> Feature Requests item #13913, was opened at 2007-09-13 19:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13913&group_id=797 Category: Story Runner Group: None Status: Open Priority: 3 Submitted By: Evan Light (sleight42) Assigned to: Nobody (None) >Summary: Scenario should treat no code block as "pending" Initial Comment: Currently, Scenario errors out when not supplied a body. It should behave similarly to "describe/it" where "it" is not required to have a code block. When a code block is not given, it is treated as pending. This could also be extended to Given/Then/When. Ultmately, this would have the benefit of allowing one to effectively document the entire User Story without having to furnish any code -- but still allowing Story Runner to generate documentation for it. I'll see about supplying a patch this evening ---------------------------------------------------------------------- >Comment By: Evan Light (sleight42) Date: 2007-09-13 23:37 Message: Patch attached. Depends upons a previous "bugfix" to the test code that I reported and patched earlier. Redundant as it is included in this patch ("exception_from"). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13913&group_id=797 From noreply at rubyforge.org Thu Sep 13 23:39:14 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 13 Sep 2007 23:39:14 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-13913 ] Scenario should treat no code block as & quot; pending& quot; Message-ID: <20070914033914.AB3DF5240BC2@rubyforge.org> Feature Requests item #13913, was opened at 2007-09-13 19:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13913&group_id=797 Category: Story Runner Group: None Status: Open Priority: 3 Submitted By: Evan Light (sleight42) Assigned to: Nobody (None) >Summary: Scenario should treat no code block as &quot;pending&quot; Initial Comment: Currently, Scenario errors out when not supplied a body. It should behave similarly to "describe/it" where "it" is not required to have a code block. When a code block is not given, it is treated as pending. This could also be extended to Given/Then/When. Ultmately, this would have the benefit of allowing one to effectively document the entire User Story without having to furnish any code -- but still allowing Story Runner to generate documentation for it. I'll see about supplying a patch this evening ---------------------------------------------------------------------- >Comment By: Evan Light (sleight42) Date: 2007-09-13 23:39 Message: Incidentally, from perusing the code a little more, it looks like Given/When/Then probably don't care whether they are given code blocks. Haven't dug into this too much yet. Was more interested in Scenario behavior first. ---------------------------------------------------------------------- Comment By: Evan Light (sleight42) Date: 2007-09-13 23:37 Message: Patch attached. Depends upons a previous "bugfix" to the test code that I reported and patched earlier. Redundant as it is included in this patch ("exception_from"). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13913&group_id=797 From noreply at rubyforge.org Fri Sep 14 15:28:22 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 14 Sep 2007 15:28:22 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-11254 ] RSpec syntax coloring and function pop-up integration in TextMate Message-ID: <20070914192822.B84275240C7C@rubyforge.org> Patches item #11254, was opened at 2007-05-31 14:43 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11254&group_id=797 Category: None Group: None Status: Closed Resolution: Accepted Priority: 3 Submitted By: Wincent Colaiuta (wincent) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: RSpec syntax coloring and function pop-up integration in TextMate Initial Comment: This patch makes two additions to the RSpec TextMate bundle to provide a better user experience: syntax coloring of RSpec keywords (before, after, describe, it), and display of behaviours and examples in the function pop-up menu. This latter feature is very useful for navigation when working with files with large numbers of specs. Examples appear indented. Now, this is my first ever TextMate customization so I am sure someone more experienced could improve on the implementation, but in its basic form it works. Shortcomings of the current implementation: - recognition occurs at the whole-line level, so syntax colouring only kicks in once you have typed the entire line - recognition simplisticly divides the behaviour and example descriptions into three parts, the "describe" (or "it"), the "do", and "everything else" between the two - this in turn means that there is no special syntax colouring of the "everything else" - it also means that examples such as: it "should be valid" do ... end will appear in the function pop-up with the enclosing quotes: "should be valid" - likewise, a behaviour like: describe User, "at creation time" do ... end Will appear in the function pop-up as: User, "at creation time" - and shared behaviours will appear as: "All controllers", :shared => true Hopefully someone with more knowledge about TextMate customization than I can address these issues, but as it stands I think the basic implementation is useful enough that life is better with the aid of these imperfect changes. Will also try to attach a screenshot with the patch to show what the pop-up looks like. ---------------------------------------------------------------------- >Comment By: Wincent Colaiuta (wincent) Date: 2007-09-14 19:28 Message: That's great to hear. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-09-13 06:14 Message: This got applied a few commits back (r2387). Thanks! ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-07-16 11:06 Message: Tried to include this comment when I attached the patch, but RubyForge logged me out (accepting the upload but rejecting the comment! darn transparent proxy...); so here it is again: Ok, Allan responded to the ticket. I'm going to attach an updated patch which uses "spec.rb" as the file extension instead of "_spec.rb". Also, Allan notes that if you have previously (implicitly) told TextMate to open ".rb" files as Ruby, you'll need to undo that in one of these ways: 1. Open a test.rb file and then switch away from Ruby and back again ? then TM notices that you?re selecting the default language, and will remove the explicit binding for ?.rb? files (ensure though that only the Ruby bundle has ?rb? declared as an extension). 2. defaults delete com.macromates.textmate OakLanguageFileBindings ? this deletes all stored bindings. ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-07-08 10:48 Message: Posted a follow-up TextMate ticket here: http://macromates.com/ticket/show?ticket_id=0F597093 ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-07-08 10:27 Message: Just attached an updated patch with "_spec.rb" denoted as file extension. ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-07-08 10:14 Message: Awesome, looks like the requested change is already implemented in the new r1405: [NEW] Add ?_? to the set of anchor characters for file types (extensions) -- ticket 48BF377 ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-07-07 18:51 Message: Ok, submitted a TextMate feature request here: http://macromates.com/ticket/show?ticket_id=48BF3775 ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-07-07 18:46 Message: Very interesting... Noticed in the changelog for the just released TextMate r1401 the following: [CHANGED] File types (extensions) specified in language grammars are now matched against the full path so e.g. ?.git/config? and ?.ssh/config? are both valid extensions -- the match is required to be anchored either at an ?/? or ?.? so e.g. ?tml? will not match ?index.html?. On a tie, the longest suffix-match is chosen. So, not quite what would be necessary to distinguish between ".rb" and "_spec.rb", but a step closer. Think I might file a TextMate feature request to accept "_" as an anchor as well; that would allow spec files to be auto-detected and auto-syntax highlighted. ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-06-25 09:21 Message: (1) The patch was made against the trunk back at the end of May (r2060, I think). The changes to the info.plist (shouldn't it be Info.plist, btw?) weren't manually done by me, but were inserted by TextMate when I made the other additions via its Bundle Editor. These settings are pretty opaque to me and omitting them seems to make no difference, so I will attach a patch against the current trunk which does not include the info.plist changes. (2) There aren't any new user-settable "preferences" as such. The two new files in the "Preferences" subdirectory of the bundle are used to add Behaviours and Examples to the TextMate symbols list... this is what allows them to appear in the pop-up. (3) To see the syntax highlighting you must select "RSpec" from the language pop-up at the bottom of the window. This is just like when you have a Rails file and want special Rails-specific highlighting instead of the default Ruby highlighting. It would be nice if TextMate allowed you to specify that all files ending in "_spec.rb" would be auto-detected as RSpec files, but as far as I know, TextMate only allows you to specify the extension part (".rb") and that would override the default Ruby highlighting. So if we want that feature we either need to try again get the RSpec syntax rolled into the Ruby.tmbundle, or try to get Allan to modify Textmate to allow us to specify not just the extension. (4) The pop-up menu is the function pop-up at the bottom of the TextMate window (right hand side). I don't know if there is a keyboard shortcut; I use the mouse for that. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-06-24 13:06 Message: This sounds great, but I'm having some problems. 1) The patch doesn't apply cleanly against trunk r2121 with "patch -p0 < textmate.diff": patching file Preferences/Symbol patching file Preferences/Symbol patching file info.plist Hunk #1 FAILED at 280. 1 out of 1 hunk FAILED -- saving rejects to file info.plist.rej patching file Syntaxes/RSpec.tmLanguage $ cat info.plist.rej *************** *** 280,285 **** 240FDD9D-CD49-4917-9003-80A3E1DADFBA B5906021-8E54-4863-A13B-EA46333DB5F1 67E726E0-63E2-4840-B8BB-37F665CD34B8 uuid 4CEA47CC-2C3A-45FB-80BE-3820828227C2 --- 280,288 ---- 240FDD9D-CD49-4917-9003-80A3E1DADFBA B5906021-8E54-4863-A13B-EA46333DB5F1 67E726E0-63E2-4840-B8BB-37F665CD34B8 + 923F0A10-96B9-4792-99A4-94FEF66E0B8C + 57EF6130-05A6-4117-94CB-C0BD63328334 + 28F89786-04F4-43D7-82A6-34B046C2BC6B uuid 4CEA47CC-2C3A-45FB-80BE-3820828227C2 2) I tried to add the three rejected lines manually, and in the bundle editor I can see the new RSpec syntax, but I don't see the new preferences. Shouldn't they show up too? 3) There is no new syntax highlighting on my Textmate. How does TextMate know to use this highlighting? Do I need to do anything special to make it work? 4) How do I bring up the list over behaviours and examples shown in your screenshot? It must be some keyboard shortcut I'm unaware of. Cheers, Aslak ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11254&group_id=797 From noreply at rubyforge.org Fri Sep 14 17:44:40 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 14 Sep 2007 17:44:40 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-13943 ] ProfileFormatter (Top 10 slowest examples) Message-ID: <20070914214440.8E7205240D1E@rubyforge.org> Patches item #13943, was opened at 2007-09-14 21:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13943&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Ian Leitch (idl) Assigned to: Nobody (None) Summary: ProfileFormatter (Top 10 slowest examples) Initial Comment: At work we have roughly 1600 examples, and they take about 45 seconds to run; a bit too long. Upgrading from 1.0.5 to 1.0.8 actually almost doubled the time it takes for our specs to run, though I haven't had the time to investigate what particular change (s) introduced the new overhead. In an attempt to improve this situation, I've created a simple formatter (attached) that times each example and produces a list of the 10 slowest. It turns out that our slowest examples are in the 0.4 seconds range, way too slow for a single example. Unsurprisingly, most of them are Rails view specs, and I suspect the rendering and response body parsing is to blame here. I plan to investigate this further down the stack and see if there is any low hanging fruit to be had. Cheers Ian Leitch ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13943&group_id=797 From noreply at rubyforge.org Fri Sep 14 23:26:19 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 14 Sep 2007 23:26:19 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-13943 ] ProfileFormatter (Top 10 slowest examples) Message-ID: <20070915032619.DE8E45240D1F@rubyforge.org> Patches item #13943, was opened at 2007-09-14 17:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13943&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Ian Leitch (idl) Assigned to: Nobody (None) Summary: ProfileFormatter (Top 10 slowest examples) Initial Comment: At work we have roughly 1600 examples, and they take about 45 seconds to run; a bit too long. Upgrading from 1.0.5 to 1.0.8 actually almost doubled the time it takes for our specs to run, though I haven't had the time to investigate what particular change (s) introduced the new overhead. In an attempt to improve this situation, I've created a simple formatter (attached) that times each example and produces a list of the 10 slowest. It turns out that our slowest examples are in the 0.4 seconds range, way too slow for a single example. Unsurprisingly, most of them are Rails view specs, and I suspect the rendering and response body parsing is to blame here. I plan to investigate this further down the stack and see if there is any low hanging fruit to be had. Cheers Ian Leitch ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-09-14 23:26 Message: Very nice. A small comment - why is it extending ProgressBarFormatter? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13943&group_id=797 From brian.takita at gmail.com Sat Sep 15 03:20:10 2007 From: brian.takita at gmail.com (Brian Takita) Date: Fri, 14 Sep 2007 21:20:10 -1000 Subject: [rspec-devel] rspec extensions In-Reply-To: <82c457760709122131j1e00822bv38c4bc954e20abec@mail.gmail.com> References: <82c457760709122131j1e00822bv38c4bc954e20abec@mail.gmail.com> Message-ID: <1d7ddd110709150020sbdbe275nb5cd2fa91bf4a713@mail.gmail.com> On 9/12/07, Nick Kallen wrote: > i know you're on vacation but i'd bet you're checking your email: Not that often. Ive been able to stay away for the most part :) I'm ccing the rspec developer list for more ideas. > > i want to add an extension to RSpec. I'd like to be able to "tag" it and > describe statements. For example: > > it "should ensure that my checkbook is balanced", :tags => [:smoke, > :accounting] do > end > > describe Checkbook, "foobar", :tags => [:fast, :accounting] do > end > > (syntax TBD) > > I then want a rake task like: > > rake spec TAGS=(fast and accounting) > rake spec TAGS=(regression or user) > > --- > > How hard would it be to do something like this? Does Rspec have a plugin > framework? Thats really interesting. There has been talk about adding tagging to rspec. I really like it. This feature would be particularly useful for mature projects where the precheckin tests are reducing productivity by being slow. Nick, do you have some other use cases in mind? rspec is a moving target. The internals in svn trunk are significantly different from the current release (1.0.8). I think such a tagging feature would be useful in rspec core. To add it to rspec core (trunk), I think the following objects need to be touched (without seeing the code): * Tagging object(s) * Example.suite * ExampleApi (describe, it, and tags methods) * ExampleDefinition (tags method) * Options (For non-rake command line arguments) * OptionParser (For non-rake command line arguments) * maybe SpecTask I suspect, in your case, you only care about rake, so you would not need to care about Options and OptionParser. Is this something that you would like to do really soon or can you wait for the next release? If you want to do it before the next release, the touch points will be a little different. The closest thing to a plugin architure is the a configuration object. The tags feature seems like it should be implementable by a plugin but now requires vertical changes (across several objects). It seems there is some work needed there. Brian From pergesu at gmail.com Sat Sep 15 03:23:35 2007 From: pergesu at gmail.com (Pat Maddox) Date: Sat, 15 Sep 2007 00:23:35 -0700 Subject: [rspec-devel] rspec extensions In-Reply-To: <1d7ddd110709150020sbdbe275nb5cd2fa91bf4a713@mail.gmail.com> References: <82c457760709122131j1e00822bv38c4bc954e20abec@mail.gmail.com> <1d7ddd110709150020sbdbe275nb5cd2fa91bf4a713@mail.gmail.com> Message-ID: <810a540e0709150023r730ada22u1d46d4f70b74fb7d@mail.gmail.com> On 9/15/07, Brian Takita wrote: > On 9/12/07, Nick Kallen wrote: > > i know you're on vacation but i'd bet you're checking your email: > Not that often. Ive been able to stay away for the most part :) > I'm ccing the rspec developer list for more ideas. > > > > i want to add an extension to RSpec. I'd like to be able to "tag" it and > > describe statements. For example: > > > > it "should ensure that my checkbook is balanced", :tags => [:smoke, > > :accounting] do > > end > > > > describe Checkbook, "foobar", :tags => [:fast, :accounting] do > > end > > > > (syntax TBD) > > > > I then want a rake task like: > > > > rake spec TAGS=(fast and accounting) > > rake spec TAGS=(regression or user) > > > > --- > > > > How hard would it be to do something like this? Does Rspec have a plugin > > framework? > Thats really interesting. There has been talk about adding tagging to rspec. > I really like it. This feature would be particularly useful for mature > projects where the precheckin tests are reducing productivity by being > slow. Nick, do you have some other use cases in mind? This is a great idea. I love it. Pat From noreply at rubyforge.org Sat Sep 15 04:47:52 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 15 Sep 2007 04:47:52 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-13943 ] ProfileFormatter (Top 10 slowest examples) Message-ID: <20070915084752.2DBDD5240A2E@rubyforge.org> Patches item #13943, was opened at 2007-09-14 21:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13943&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Ian Leitch (idl) Assigned to: Nobody (None) Summary: ProfileFormatter (Top 10 slowest examples) Initial Comment: At work we have roughly 1600 examples, and they take about 45 seconds to run; a bit too long. Upgrading from 1.0.5 to 1.0.8 actually almost doubled the time it takes for our specs to run, though I haven't had the time to investigate what particular change (s) introduced the new overhead. In an attempt to improve this situation, I've created a simple formatter (attached) that times each example and produces a list of the 10 slowest. It turns out that our slowest examples are in the 0.4 seconds range, way too slow for a single example. Unsurprisingly, most of them are Rails view specs, and I suspect the rendering and response body parsing is to blame here. I plan to investigate this further down the stack and see if there is any low hanging fruit to be had. Cheers Ian Leitch ---------------------------------------------------------------------- >Comment By: Ian Leitch (idl) Date: 2007-09-15 08:47 Message: It extends ProgressBarFormatter just to give the user some indication of progress while it's running. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-09-15 03:26 Message: Very nice. A small comment - why is it extending ProgressBarFormatter? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13943&group_id=797 From noreply at rubyforge.org Sat Sep 15 07:05:06 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 15 Sep 2007 07:05:06 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-13952 ] Fix for performance regression introduced in r2096 Message-ID: <20070915110506.EBDF25240AEB@rubyforge.org> Patches item #13952, was opened at 2007-09-15 11:05 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13952&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Ian Leitch (idl) Assigned to: Nobody (None) Summary: Fix for performance regression introduced in r2096 Initial Comment: Bug report 11545 pointed out an issue where RSpec would attempt to proxy a method on an ActiveRecord class which lies about the presence of methods by overriding responds_to?. The fix for that bug used a search on instance_methods to ensure the method actually exists, specifically: instance_methods.include?(sym.to_s). On my laptop, this introduced a 2x performance regression. As a result, my spec suite went from running in 20 seconds to 40. This patch almost completely eliminates the overhead by using method_defined? instead. Cheers Ian Leitch P.S svn _badly_ needs an equivalent of git bisect! ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13952&group_id=797 From noreply at rubyforge.org Sat Sep 15 09:39:56 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 15 Sep 2007 09:39:56 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-13952 ] Fix for performance regression introduced in r2096 Message-ID: <20070915133956.C9DD45240AF8@rubyforge.org> Patches item #13952, was opened at 2007-09-15 07:05 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13952&group_id=797 >Category: mock module Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Ian Leitch (idl) >Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Fix for performance regression introduced in r2096 Initial Comment: Bug report 11545 pointed out an issue where RSpec would attempt to proxy a method on an ActiveRecord class which lies about the presence of methods by overriding responds_to?. The fix for that bug used a search on instance_methods to ensure the method actually exists, specifically: instance_methods.include?(sym.to_s). On my laptop, this introduced a 2x performance regression. As a result, my spec suite went from running in 20 seconds to 40. This patch almost completely eliminates the overhead by using method_defined? instead. Cheers Ian Leitch P.S svn _badly_ needs an equivalent of git bisect! ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-09-15 09:39 Message: Thanks! Applied in r2096 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13952&group_id=797 From mmangino at elevatedrails.com Sat Sep 15 10:57:49 2007 From: mmangino at elevatedrails.com (Mike Mangino) Date: Sat, 15 Sep 2007 09:57:49 -0500 Subject: [rspec-devel] Fix for should == mock_model with ActiveRecord Message-ID: <38515CF5-B798-4A1A-93DC-6ED64EDF2BA2@elevatedrails.com> I've attached a fix for the problems using specs like it "should belong to a user" do @comment.user.should == @user end where @user is a mock_model. To summarize the issue, rspec mocks use a proxy (__mock_proxy) to delegate methods to. When on the LHS, == is delegated to the proxy. On the RHS, however, we are comparing the mock itself to the proxy. There are a couple of potential fixes. We could actually check to see if the RHS is a mock, and if so, compare our proxy to its proxy. Alternatively, we could take the naive solution and just reverse the comparison. I've attached the patch. I'm open to other suggestions, but I would really like to see this fixed in some form. Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: mock_model_fix.patch Type: application/octet-stream Size: 2483 bytes Desc: not available Url : http://rubyforge.org/pipermail/rspec-devel/attachments/20070915/e43b611e/attachment.obj -------------- next part -------------- -- Mike Mangino http://www.elevatedrails.com From nick at pivotalsf.com Sat Sep 15 14:20:02 2007 From: nick at pivotalsf.com (Nick Kallen) Date: Sat, 15 Sep 2007 11:20:02 -0700 Subject: [rspec-devel] rspec extensions In-Reply-To: <1d7ddd110709150020sbdbe275nb5cd2fa91bf4a713@mail.gmail.com> References: <82c457760709122131j1e00822bv38c4bc954e20abec@mail.gmail.com> <1d7ddd110709150020sbdbe275nb5cd2fa91bf4a713@mail.gmail.com> Message-ID: <82c457760709151120m4574f1b3t5c57f873fff3c33@mail.gmail.com> I can wait for the next release... When is it coming out? Perhaps we can convince Rob to let you and I pair on this. I'd like to be involved so I get some credit... ;) I have a couple use cases for tags, but in general the idea is to be able to run a smaller subset of tests so that you can check in more frequently. Obvious partitions include "fast" and "slow" (or as I prefer, "smoke" and "regression", which is not equivalent to "fast" and "slow"). Less obvious, but equally valuable, is to partition your test suites by functionality "verticals". For example, being able to run all accounting-related tests, or user-related tests, or asset-related tests, etc. Often these "verticals" cut across files and describe-blocks (at least, in rails, they cut across model, view, helper, and controller specs--but typically also multiple models are involved.). ---- I've also been wondering how hard it would be to make the test runner into a scheduler. What if we could have four databases: application_test_1, application_test_2, etc. And have the test runner create 4 Rails environments on the fly and run tests in parallel across them. Some thoughtworks people have been parallelizing tests by running them all in individual transactions. The problem here is that fixtures aren't inserted as transactions so it excludes fixture-based tests. You can load the fixtures in transactions but since Transactions involve full-table locks, in effect the tests don't run in parallel. The "scheduling" approach seems to me more sensible. The only issue is migrating 4 sep databases which can probably be done very rapidly by means of schema.rb or a dump from one db to the next. On 9/15/07, Brian Takita wrote: > > On 9/12/07, Nick Kallen wrote: > > i know you're on vacation but i'd bet you're checking your email: > Not that often. Ive been able to stay away for the most part :) > I'm ccing the rspec developer list for more ideas. > > > > i want to add an extension to RSpec. I'd like to be able to "tag" it and > > describe statements. For example: > > > > it "should ensure that my checkbook is balanced", :tags => [:smoke, > > :accounting] do > > end > > > > describe Checkbook, "foobar", :tags => [:fast, :accounting] do > > end > > > > (syntax TBD) > > > > I then want a rake task like: > > > > rake spec TAGS=(fast and accounting) > > rake spec TAGS=(regression or user) > > > > --- > > > > How hard would it be to do something like this? Does Rspec have a plugin > > framework? > Thats really interesting. There has been talk about adding tagging to > rspec. > I really like it. This feature would be particularly useful for mature > projects where the precheckin tests are reducing productivity by being > slow. Nick, do you have some other use cases in mind? > > rspec is a moving target. The internals in svn trunk are significantly > different from the current release (1.0.8). > > I think such a tagging feature would be useful in rspec core. To add > it to rspec core (trunk), I think the following objects need to be > touched (without seeing the code): > * Tagging object(s) > * Example.suite > * ExampleApi (describe, it, and tags methods) > * ExampleDefinition (tags method) > * Options (For non-rake command line arguments) > * OptionParser (For non-rake command line arguments) > * maybe SpecTask > > I suspect, in your case, you only care about rake, so you would not > need to care about Options and OptionParser. > > Is this something that you would like to do really soon or can you > wait for the next release? > > If you want to do it before the next release, the touch points will be > a little different. > > The closest thing to a plugin architure is the a configuration object. > The tags feature seems like it should be implementable by a plugin but > now requires vertical changes (across several objects). It seems there > is some work needed there. > > Brian > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070915/92ff0733/attachment-0001.html From noreply at rubyforge.org Sat Sep 15 15:22:47 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 15 Sep 2007 15:22:47 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-13968 ] Edge Rails removes JavaScriptMacrosHelper Message-ID: <20070915192247.38C535240B8F@rubyforge.org> Patches item #13968, was opened at 2007-09-15 14:22 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13968&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Sean Cribbs (seancribbs) Assigned to: Nobody (None) Summary: Edge Rails removes JavaScriptMacrosHelper Initial Comment: The latest version of Edge Rails removes ActionView::Helpers::JavaScriptMacrosHelper, which causes specs to fail because the DSL attempts to load the helper. Patch attached. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13968&group_id=797 From noreply at rubyforge.org Sat Sep 15 16:49:19 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 15 Sep 2007 16:49:19 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-13969 ] Spec Failures on Trunk w/ Autotest Message-ID: <20070915204920.1ADDC5240C34@rubyforge.org> Bugs item #13969, was opened at 2007-09-15 20:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13969&group_id=797 Category: Autotest Group: None Status: Open Resolution: None Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) Assigned to: Nobody (None) Summary: Spec Failures on Trunk w/ Autotest Initial Comment: Spec Failures are occurring when using autotest, but not when using the rake task: (This is occuring in trunk/rspec, at revision 2564): ------------------------------------------------------------------------- escher: autotest loading autotest/rspec /sw/bin/ruby1.8 -S bin/spec spec/spec/dsl/composite_proc_builder_spec.rb spec/spec/translator_spec.rb spec/spec/runner/option_parser_spec.rb spec/spec/dsl/predicate_matcher_spec.rb spec/spec/runner/heckler_spec.rb spec/spec/mocks/partial_mock_using_mocks_directly_spec.rb spec/spec/matchers/matcher_methods_spec.rb spec/spec/story/rspec_adapter.rb spec/spec/mocks/record_messages_spec.rb spec/spec/runner/formatter/failing_behaviours_formatter_spec.rb spec/spec/runner/command_line_spec.rb spec/spec/dsl/configuration_spec.rb spec/spec/runner/extensions/bug_report_10577_spec.rb spec/spec/matchers/operator_matcher_spec.rb spec/spec/matchers/be_spec.rb spec/spec/matchers/be_close_spec.rb spec/spec/runner/test_unit_and_rspec_spec.rb spec/spec/runner/formatter/progress_bar_formatter_spec.rb spec/spec/mocks/multiple_return_value_spec.rb spec/spec/runner/formatter/snippet_extractor_spec.rb spec/spec/package/bin_spec_spec.rb spec/spec/runner/reporter_spec.rb spec/spec/runner_spec.rb spec/spec/mocks/stub_spec.rb spec/spec/matchers/description_generation_spec.rb spec/spec/runner/formatter/html_formatter_spec.rb spec/spec/expectations/fail_with_spec.rb spec/spec/matchers/equal_spec.rb spec/spec/mocks/bug_report_7805_spec.rb spec/spec/runner/spec_parser_spec.rb spec/spec/runner/behaviour_runner_spec.rb spec/autotest/discover_spec.rb spec/spec/story/simple_step_spec.rb spec/spec/runner/quiet_backtrace_tweaker_spec.rb spec/spec/story/runner/scenario_runner_spec.rb spec/spec/runner/formatter/progress_bar_formatter_failure_dump_spec.rb spec/spec/runner/heckle_runner_spec.rb spec/spec/mocks/failing_mock_argument_constraints_spec.rb spec/spec/matchers/satisfy_spec.rb spec/spec/dsl/example_instance_spec.rb spec/spec/story/world_spec.rb spec/spec/story/story_spec.rb spec/spec/mocks/at_most_spec.rb spec/spec/mocks/bug_report_11545_spec.rb spec/spec/mocks/mock_ordering_spec.rb spec/spec/dsl/example_matcher_spec.rb spec/spec/story/given_scenario_spec.rb spec/spec/dsl/example_factory_spec.rb spec/spec/runner/formatter/specdoc_formatter_dry_run_spec.rb spec/spec/mocks/bug_report_10260_spec.rb spec/spec/mocks/precise_counts_spec.rb spec/spec/mocks/at_least_spec.rb spec/spec/story/runner_spec.rb spec/spec/runner/testrunnermediator_spec.rb spec/spec/mocks/bug_report_8302_spec.rb spec/spec/dsl/shared_behaviour_spec.rb spec/spec/mocks/passing_mock_argument_constraints_spec.rb spec/spec/runner/formatter/rdoc_formatter_dry_run_spec.rb spec/spec/story/runner/scenario_collector_spec.rb spec/spec/mocks/argument_expectation_spec.rb spec/spec/runner/options_spec.rb spec/spec/matchers/mock_constraint_matchers_spec.rb spec/spec/mocks/any_number_of_times_spec.rb spec/spec/matchers/has_spec.rb spec/spec/runner/object_ext_spec.rb spec/spec/mocks/options_hash_spec.rb spec/spec/dsl/example_definition_class_spec.rb spec/spec/matchers/respond_to_spec.rb spec/spec/mocks/mock_spec.rb spec/spec/mocks/bug_report_7611_spec.rb spec/spec/mocks/once_counts_spec.rb spec/spec/story/runner/story_runner_spec.rb spec/spec/runner/formatter/progress_bar_formatter_dry_run_spec.rb spec/spec/runner/formatter/specdoc_formatter_spec.rb spec/spec/matchers/handler_spec.rb spec/spec/story/step_mother_spec.rb spec/spec/runner/noisy_backtrace_tweaker_spec.rb spec/spec/matchers/eql_spec.rb spec/spec/matchers/include_spec.rb spec/autotest_helper.rb spec/spec/dsl/example_should_raise_spec.rb spec/rspec_suite.rb spec/spec/dsl/behaviour_description_spec.rb spec/spec/runner/formatter/rdoc_formatter_spec.rb spec/spec/spec_classes.rb spec/autotest/rspec_spec.rb spec/spec/story/reporter/plain_text_reporter_spec.rb spec/spec/story/story_helper.rb spec/spec/mocks/bug_report_8165_spec.rb spec/spec/story/documenter/plain_text_documenter_spec.rb spec/spec/matchers/change_spec.rb spec/spec/runner/execution_context_spec.rb spec/spec/mocks/twice_counts_spec.rb spec/spec/mocks/null_object_mock_spec.rb spec/spec/dsl/example_class_definition_spec.rb spec/spec/matchers/simple_matcher_spec.rb spec/spec/matchers/have_spec.rb spec/spec/matchers/raise_error_spec.rb spec/spec/mocks/mock_space_spec.rb spec/spec/runner/drb_command_line_spec.rb spec/spec/story/builders.rb spec/spec/dsl/example_suite_spec.rb spec/spec/runner/extensions/kernel_spec.rb spec/spec/dsl/example_spec.rb spec/spec/story/extensions_spec.rb spec/spec/dsl/example_definition_spec.rb spec/spec/expectations/differs/default_spec.rb spec/spec/runner/formatter/failing_examples_formatter_spec.rb spec/spec/story/scenario_spec.rb spec/spec/dsl/supports_pending_spec.rb spec/spec/matchers/throw_symbol_spec.rb spec/spec/matchers/match_spec.rb spec/spec/matchers/exist_spec.rb spec/spec/expectations/extensions/object_spec.rb spec/spec/mocks/partial_mock_spec.rb ..........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................P.....................................................................................................................................................................................................................................................................................................................................................P.......PP..................................F..F..........P.............. 1) 'should match(expected) should fail when target (String) matches expected (Regexp)' FAILED expected Spec::Expectations::ExpectationNotMetError, got #> ./spec/spec/matchers/match_spec.rb:9: 2) 'should_not match(expected) should fail when target (String) matches expected (Regexp)' FAILED expected Spec::Expectations::ExpectationNotMetError, got #> ./spec/spec/matchers/match_spec.rb:27: Finished in 5.699199 seconds 1049 examples, 2 failures, 5 pending Pending: a Mock expectation should clear expectations after verify (this fails if you run the file normally, but passes if you comment out the example at 116 or run the file in reverse) Example.suite should return an ExampleSuite with Examples (Not Yet Implemented) Example.class_eval should understand module scoping (Example.new needs to create a class that is evaled) Example.class_eval should allow class variables to be defined (class_eval cannot be used. Only the class definition can be used. This may not be possible.) Object#should should raise error if it receives nil (refactor the should method to handle this) ^CInterrupt a second time to quit ^Cescher: rake spec (in /Users/smt/src/ruby/rspec/trunk/rspec) ...............................................................................................................P.......PP..........................................................................P................................................................................................................................................................................................................................................................................................................................................................................................P............................................................................................................................................................................................................................................................................................................................................................................................................................................... Finished in 9.799042 seconds 1012 examples, 0 failures, 5 pending Pending: Example.suite should return an ExampleSuite with Examples (Not Yet Implemented) Example.class_eval should understand module scoping (Example.new needs to create a class that is evaled) Example.class_eval should allow class variables to be defined (class_eval cannot be used. Only the class definition can be used. This may not be possible.) Object#should should raise error if it receives nil (refactor the should method to handle this) a Mock expectation should clear expectations after verify (this fails if you run the file normally, but passes if you comment out the example at 116 or run the file in reverse) -------------------------------------------------------------------------------- Not sure if this has anything to do with Autotest or not. My suspicion is that it's buggy (rspec, not autotest) code. Let me know if I can do anything to help. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13969&group_id=797 From noreply at rubyforge.org Sat Sep 15 16:57:05 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 15 Sep 2007 16:57:05 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-13969 ] Spec Failures on Trunk w/ Autotest Message-ID: <20070915205705.64FCE5240C04@rubyforge.org> Bugs item #13969, was opened at 2007-09-15 20:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13969&group_id=797 Category: Autotest Group: None Status: Open Resolution: None Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) Assigned to: Nobody (None) Summary: Spec Failures on Trunk w/ Autotest Initial Comment: Spec Failures are occurring when using autotest, but not when using the rake task: (This is occuring in trunk/rspec, at revision 2564): ------------------------------------------------------------------------- escher: autotest loading autotest/rspec /sw/bin/ruby1.8 -S bin/spec spec/spec/dsl/composite_proc_builder_spec.rb spec/spec/translator_spec.rb spec/spec/runner/option_parser_spec.rb spec/spec/dsl/predicate_matcher_spec.rb spec/spec/runner/heckler_spec.rb spec/spec/mocks/partial_mock_using_mocks_directly_spec.rb spec/spec/matchers/matcher_methods_spec.rb spec/spec/story/rspec_adapter.rb spec/spec/mocks/record_messages_spec.rb spec/spec/runner/formatter/failing_behaviours_formatter_spec.rb spec/spec/runner/command_line_spec.rb spec/spec/dsl/configuration_spec.rb spec/spec/runner/extensions/bug_report_10577_spec.rb spec/spec/matchers/operator_matcher_spec.rb spec/spec/matchers/be_spec.rb spec/spec/matchers/be_close_spec.rb spec/spec/runner/test_unit_and_rspec_spec.rb spec/spec/runner/formatter/progress_bar_formatter_spec.rb spec/spec/mocks/multiple_return_value_spec.rb spec/spec/runner/formatter/snippet_extractor_spec.rb spec/spec/package/bin_spec_spec.rb spec/spec/runner/reporter_spec.rb spec/spec/runner_spec.rb spec/spec/mocks/stub_spec.rb spec/spec/matchers/description_generation_spec.rb spec/spec/runner/formatter/html_formatter_spec.rb spec/spec/expectations/fail_with_spec.rb spec/spec/matchers/equal_spec.rb spec/spec/mocks/bug_report_7805_spec.rb spec/spec/runner/spec_parser_spec.rb spec/spec/runner/behaviour_runner_spec.rb spec/autotest/discover_spec.rb spec/spec/story/simple_step_spec.rb spec/spec/runner/quiet_backtrace_tweaker_spec.rb spec/spec/story/runner/scenario_runner_spec.rb spec/spec/runner/formatter/progress_bar_formatter_failure_dump_spec.rb spec/spec/runner/heckle_runner_spec.rb spec/spec/mocks/failing_mock_argument_constraints_spec.rb spec/spec/matchers/satisfy_spec.rb spec/spec/dsl/example_instance_spec.rb spec/spec/story/world_spec.rb spec/spec/story/story_spec.rb spec/spec/mocks/at_most_spec.rb spec/spec/mocks/bug_report_11545_spec.rb spec/spec/mocks/mock_ordering_spec.rb spec/spec/dsl/example_matcher_spec.rb spec/spec/story/given_scenario_spec.rb spec/spec/dsl/example_factory_spec.rb spec/spec/runner/formatter/specdoc_formatter_dry_run_spec.rb spec/spec/mocks/bug_report_10260_spec.rb spec/spec/mocks/precise_counts_spec.rb spec/spec/mocks/at_least_spec.rb spec/spec/story/runner_spec.rb spec/spec/runner/testrunnermediator_spec.rb spec/spec/mocks/bug_report_8302_spec.rb spec/spec/dsl/shared_behaviour_spec.rb spec/spec/mocks/passing_mock_argument_constraints_spec.rb spec/spec/runner/formatter/rdoc_formatter_dry_run_spec.rb spec/spec/story/runner/scenario_collector_spec.rb spec/spec/mocks/argument_expectation_spec.rb spec/spec/runner/options_spec.rb spec/spec/matchers/mock_constraint_matchers_spec.rb spec/spec/mocks/any_number_of_times_spec.rb spec/spec/matchers/has_spec.rb spec/spec/runner/object_ext_spec.rb spec/spec/mocks/options_hash_spec.rb spec/spec/dsl/example_definition_class_spec.rb spec/spec/matchers/respond_to_spec.rb spec/spec/mocks/mock_spec.rb spec/spec/mocks/bug_report_7611_spec.rb spec/spec/mocks/once_counts_spec.rb spec/spec/story/runner/story_runner_spec.rb spec/spec/runner/formatter/progress_bar_formatter_dry_run_spec.rb spec/spec/runner/formatter/specdoc_formatter_spec.rb spec/spec/matchers/handler_spec.rb spec/spec/story/step_mother_spec.rb spec/spec/runner/noisy_backtrace_tweaker_spec.rb spec/spec/matchers/eql_spec.rb spec/spec/matchers/include_spec.rb spec/autotest_helper.rb spec/spec/dsl/example_should_raise_spec.rb spec/rspec_suite.rb spec/spec/dsl/behaviour_description_spec.rb spec/spec/runner/formatter/rdoc_formatter_spec.rb spec/spec/spec_classes.rb spec/autotest/rspec_spec.rb spec/spec/story/reporter/plain_text_reporter_spec.rb spec/spec/story/story_helper.rb spec/spec/mocks/bug_report_8165_spec.rb spec/spec/story/documenter/plain_text_documenter_spec.rb spec/spec/matchers/change_spec.rb spec/spec/runner/execution_context_spec.rb spec/spec/mocks/twice_counts_spec.rb spec/spec/mocks/null_object_mock_spec.rb spec/spec/dsl/example_class_definition_spec.rb spec/spec/matchers/simple_matcher_spec.rb spec/spec/matchers/have_spec.rb spec/spec/matchers/raise_error_spec.rb spec/spec/mocks/mock_space_spec.rb spec/spec/runner/drb_command_line_spec.rb spec/spec/story/builders.rb spec/spec/dsl/example_suite_spec.rb spec/spec/runner/extensions/kernel_spec.rb spec/spec/dsl/example_spec.rb spec/spec/story/extensions_spec.rb spec/spec/dsl/example_definition_spec.rb spec/spec/expectations/differs/default_spec.rb spec/spec/runner/formatter/failing_examples_formatter_spec.rb spec/spec/story/scenario_spec.rb spec/spec/dsl/supports_pending_spec.rb spec/spec/matchers/throw_symbol_spec.rb spec/spec/matchers/match_spec.rb spec/spec/matchers/exist_spec.rb spec/spec/expectations/extensions/object_spec.rb spec/spec/mocks/partial_mock_spec.rb ..........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................P.....................................................................................................................................................................................................................................................................................................................................................P.......PP..................................F..F..........P.............. 1) 'should match(expected) should fail when target (String) matches expected (Regexp)' FAILED expected Spec::Expectations::ExpectationNotMetError, got #> ./spec/spec/matchers/match_spec.rb:9: 2) 'should_not match(expected) should fail when target (String) matches expected (Regexp)' FAILED expected Spec::Expectations::ExpectationNotMetError, got #> ./spec/spec/matchers/match_spec.rb:27: Finished in 5.699199 seconds 1049 examples, 2 failures, 5 pending Pending: a Mock expectation should clear expectations after verify (this fails if you run the file normally, but passes if you comment out the example at 116 or run the file in reverse) Example.suite should return an ExampleSuite with Examples (Not Yet Implemented) Example.class_eval should understand module scoping (Example.new needs to create a class that is evaled) Example.class_eval should allow class variables to be defined (class_eval cannot be used. Only the class definition can be used. This may not be possible.) Object#should should raise error if it receives nil (refactor the should method to handle this) ^CInterrupt a second time to quit ^Cescher: rake spec (in /Users/smt/src/ruby/rspec/trunk/rspec) ...............................................................................................................P.......PP..........................................................................P................................................................................................................................................................................................................................................................................................................................................................................................P............................................................................................................................................................................................................................................................................................................................................................................................................................................... Finished in 9.799042 seconds 1012 examples, 0 failures, 5 pending Pending: Example.suite should return an ExampleSuite with Examples (Not Yet Implemented) Example.class_eval should understand module scoping (Example.new needs to create a class that is evaled) Example.class_eval should allow class variables to be defined (class_eval cannot be used. Only the class definition can be used. This may not be possible.) Object#should should raise error if it receives nil (refactor the should method to handle this) a Mock expectation should clear expectations after verify (this fails if you run the file normally, but passes if you comment out the example at 116 or run the file in reverse) -------------------------------------------------------------------------------- Not sure if this has anything to do with Autotest or not. My suspicion is that it's buggy (rspec, not autotest) code. Let me know if I can do anything to help. ---------------------------------------------------------------------- >Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-09-15 20:57 Message: Oops: Forgot to attach my info: Ruby v. 186 Mac OS X.4.10 (Intel) rspec's trunk autotest, latest gem ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13969&group_id=797 From noreply at rubyforge.org Sat Sep 15 17:01:33 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 15 Sep 2007 17:01:33 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-13968 ] Edge Rails removes JavaScriptMacrosHelper Message-ID: <20070915210133.EFEF55240C23@rubyforge.org> Patches item #13968, was opened at 2007-09-15 19:22 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13968&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Out of Date Priority: 3 Submitted By: Sean Cribbs (seancribbs) Assigned to: Nobody (None) Summary: Edge Rails removes JavaScriptMacrosHelper Initial Comment: The latest version of Edge Rails removes ActionView::Helpers::JavaScriptMacrosHelper, which causes specs to fail because the DSL attempts to load the helper. Patch attached. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-15 21:01 Message: This problem was eliminated in r2562 with patch 13881. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13968&group_id=797 From aslak.hellesoy at gmail.com Sat Sep 15 17:27:29 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sat, 15 Sep 2007 23:27:29 +0200 Subject: [rspec-devel] Fix for should == mock_model with ActiveRecord In-Reply-To: <38515CF5-B798-4A1A-93DC-6ED64EDF2BA2@elevatedrails.com> References: <38515CF5-B798-4A1A-93DC-6ED64EDF2BA2@elevatedrails.com> Message-ID: <8d961d900709151427r1153a164nb8a17a38e20c3a3d@mail.gmail.com> Thanks for the patch, Please put this in the tracker on Rubyforge so it stays on our radar. It's guaranteed to be forgotten here on the list. Aslak On 9/15/07, Mike Mangino wrote: > I've attached a fix for the problems using specs like > > it "should belong to a user" do > @comment.user.should == @user > end > > where @user is a mock_model. > > > To summarize the issue, > > rspec mocks use a proxy (__mock_proxy) to delegate methods to. When > on the LHS, == is delegated to the proxy. On the RHS, however, we are > comparing the mock itself to the proxy. There are a couple of > potential fixes. > > We could actually check to see if the RHS is a mock, and if so, > compare our proxy to its proxy. Alternatively, we could take the > naive solution and just reverse the comparison. > > I've attached the patch. I'm open to other suggestions, but I would > really like to see this fixed in some form. > > Mike > > > > -- > Mike Mangino > http://www.elevatedrails.com > > > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > From aslak.hellesoy at gmail.com Sat Sep 15 17:31:36 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sat, 15 Sep 2007 23:31:36 +0200 Subject: [rspec-devel] rspec extensions In-Reply-To: <82c457760709151120m4574f1b3t5c57f873fff3c33@mail.gmail.com> References: <82c457760709122131j1e00822bv38c4bc954e20abec@mail.gmail.com> <1d7ddd110709150020sbdbe275nb5cd2fa91bf4a713@mail.gmail.com> <82c457760709151120m4574f1b3t5c57f873fff3c33@mail.gmail.com> Message-ID: <8d961d900709151431t13e247a3vf7489d084950b754@mail.gmail.com> I agree that this is a compelling feature, especially for large suites of slow specs. Java's TestNG has this feature already. We alreadt have a mechanism for "tagging" behaviours using :behaviour_type, and I think we should use the existing mechanism. We can rename it if need be - TestNG calls it group, but :tag or :tags is fine too - I like that. Aslak On 9/15/07, Nick Kallen wrote: > I can wait for the next release... When is it coming out? Perhaps we can > convince Rob to let you and I pair on this. I'd like to be involved so I get > some credit... ;) > > I have a couple use cases for tags, but in general the idea is to be able to > run a smaller subset of tests so that you can check in more frequently. > Obvious partitions include "fast" and "slow" (or as I prefer, "smoke" and > "regression", which is not equivalent to "fast" and "slow"). Less obvious, > but equally valuable, is to partition your test suites by functionality > "verticals". For example, being able to run all accounting-related tests, or > user-related tests, or asset-related tests, etc. Often these "verticals" cut > across files and describe-blocks (at least, in rails, they cut across model, > view, helper, and controller specs--but typically also multiple models are > involved.). > > ---- > > I've also been wondering how hard it would be to make the test runner into a > scheduler. What if we could have four databases: > > application_test_1, application_test_2, etc. > > And have the test runner create 4 Rails environments on the fly and run > tests in parallel across them. Some thoughtworks people have been > parallelizing tests by running them all in individual transactions. The > problem here is that fixtures aren't inserted as transactions so it excludes > fixture-based tests. You can load the fixtures in transactions but since > Transactions involve full-table locks, in effect the tests don't run in > parallel. The "scheduling" approach seems to me more sensible. The only > issue is migrating 4 sep databases which can probably be done very rapidly > by means of schema.rb or a dump from one db to the next. > > On 9/15/07, Brian Takita wrote: > > On 9/12/07, Nick Kallen wrote: > > > i know you're on vacation but i'd bet you're checking your email: > > Not that often. Ive been able to stay away for the most part :) > > I'm ccing the rspec developer list for more ideas. > > > > > > i want to add an extension to RSpec. I'd like to be able to "tag" it and > > > describe statements. For example: > > > > > > it "should ensure that my checkbook is balanced", :tags => [:smoke, > > > :accounting] do > > > end > > > > > > describe Checkbook, "foobar", :tags => [:fast, :accounting] do > > > end > > > > > > (syntax TBD) > > > > > > I then want a rake task like: > > > > > > rake spec TAGS=(fast and accounting) > > > rake spec TAGS=(regression or user) > > > > > > --- > > > > > > How hard would it be to do something like this? Does Rspec have a plugin > > > framework? > > Thats really interesting. There has been talk about adding tagging to > rspec. > > I really like it. This feature would be particularly useful for mature > > projects where the precheckin tests are reducing productivity by being > > slow. Nick, do you have some other use cases in mind? > > > > rspec is a moving target. The internals in svn trunk are significantly > > different from the current release (1.0.8). > > > > I think such a tagging feature would be useful in rspec core. To add > > it to rspec core (trunk), I think the following objects need to be > > touched (without seeing the code): > > * Tagging object(s) > > * Example.suite > > * ExampleApi (describe, it, and tags methods) > > * ExampleDefinition (tags method) > > * Options (For non-rake command line arguments) > > * OptionParser (For non-rake command line arguments) > > * maybe SpecTask > > > > I suspect, in your case, you only care about rake, so you would not > > need to care about Options and OptionParser. > > > > Is this something that you would like to do really soon or can you > > wait for the next release? > > > > If you want to do it before the next release, the touch points will be > > a little different. > > > > The closest thing to a plugin architure is the a configuration object. > > The tags feature seems like it should be implementable by a plugin but > > now requires vertical changes (across several objects). It seems there > > is some work needed there. > > > > Brian > > > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From noreply at rubyforge.org Sat Sep 15 17:41:19 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 15 Sep 2007 17:41:19 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-13370 ] Weird mock expectation error Message-ID: <20070915214119.3F0C85240B9C@rubyforge.org> Bugs item #13370, was opened at 2007-08-25 19:01 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13370&group_id=797 Category: mock module Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Yurii Rashkovskii (yrashk) Assigned to: Nobody (None) Summary: Weird mock expectation error Initial Comment: While running code that contains @user.should_receive(:assigned_to?).with(@issue).any_number_of_times.and_return true # @issue is a mock as well I'm getting weird failure: Mock 'User_1263' expected :assigned_to? with (#) but received it with (#) Any ideas? P.S. trunk rspec ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-15 21:41 Message: Fixed in r2565 - thanks to Mike Mangino for the patch. ---------------------------------------------------------------------- Comment By: Yurii Rashkovskii (yrashk) Date: 2007-08-26 12:07 Message: ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-08-25 19:31 Message: Hey Yurii: there is no plan, so feel free to submit a patch if you can figure something out that makes sense. The problem is that Rails assoc proxy objects lie about who they are and ActiveRecord does type checking on associated collections. RSpec's mock_model creates an object that, similar to Rails, lies about its identity in order to pass Rails' type checking. So you're getting two DIFFERENT OBJECTS that are both lying about their identity. RSpec is doing its job correctly (they really are two different objects and your spec *should* fail), but because both objects are impersonating something else, you get confusing/misleading feedback. FYI - you'd get the same feedback from any mock framework (try it w/ mocha and/or flexmock). ---------------------------------------------------------------------- Comment By: Yurii Rashkovskii (yrashk) Date: 2007-08-25 19:12 Message: Any chance this will be fixed? Could I help? I urgently need to get this fixed or workarounded :) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-08-25 19:05 Message: This has come up recently. If @issue is a mock, then make sure that the object it is being compared to is not a rails AssociationProxy, which will tell you that it is the model object even though it is not. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13370&group_id=797 From dchelimsky at gmail.com Sat Sep 15 17:44:25 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 15 Sep 2007 23:44:25 +0200 Subject: [rspec-devel] Fix for should == mock_model with ActiveRecord In-Reply-To: <8d961d900709151427r1153a164nb8a17a38e20c3a3d@mail.gmail.com> References: <38515CF5-B798-4A1A-93DC-6ED64EDF2BA2@elevatedrails.com> <8d961d900709151427r1153a164nb8a17a38e20c3a3d@mail.gmail.com> Message-ID: <57c63afe0709151444w42f811cdy6df99c19b513992d@mail.gmail.com> This was actually the solution to a known bug int the tracker (http://rubyforge.org/tracker/index.php?func=detail&aid=13370&group_id=797&atid=3149). I went ahead and applied it and credited you (Mike) w/ the patch, but please do put patches in the tracker rather than hear - as Aslak said, reduces the likelihood of stuff getting lost. Thanks, David On 9/15/07, aslak hellesoy wrote: > Thanks for the patch, > > Please put this in the tracker on Rubyforge so it stays on our radar. > It's guaranteed to be forgotten here on the list. > > Aslak > > On 9/15/07, Mike Mangino wrote: > > I've attached a fix for the problems using specs like > > > > it "should belong to a user" do > > @comment.user.should == @user > > end > > > > where @user is a mock_model. > > > > > > To summarize the issue, > > > > rspec mocks use a proxy (__mock_proxy) to delegate methods to. When > > on the LHS, == is delegated to the proxy. On the RHS, however, we are > > comparing the mock itself to the proxy. There are a couple of > > potential fixes. > > > > We could actually check to see if the RHS is a mock, and if so, > > compare our proxy to its proxy. Alternatively, we could take the > > naive solution and just reverse the comparison. > > > > I've attached the patch. I'm open to other suggestions, but I would > > really like to see this fixed in some form. > > > > Mike > > > > > > > > -- > > Mike Mangino > > http://www.elevatedrails.com > > > > > > > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From noreply at rubyforge.org Sun Sep 16 04:02:47 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 16 Sep 2007 04:02:47 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-13759 ] rails_rspec overwrites test mappings added in .autotest Message-ID: <20070916080247.D91675240DC5@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. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-16 08:02 Message: I added the failing example to r2566 (set to pending). We got rid of the matcher when we added a default set of predicate matchers that included exist. We only added that to the ExampleApi, so we'd need to move the whole predicate matchers bit over to Spec::Matchers to get it to work. This is now on the radar but not first priority. If you can figure out how to do that, feel free to submit another patch. Otherwise, we'll get to it eventually. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-09-13 06:16 Message: Please post your .autotest file so I can see this in action. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13759&group_id=797 From noreply at rubyforge.org Sun Sep 16 04:04:30 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 16 Sep 2007 04:04:30 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-13759 ] rails_rspec overwrites test mappings added in .autotest Message-ID: <20070916080430.C970B5240E5B@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. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-16 08:04 Message: Disregard that last message - wrong ticket. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-09-16 08:02 Message: I added the failing example to r2566 (set to pending). We got rid of the matcher when we added a default set of predicate matchers that included exist. We only added that to the ExampleApi, so we'd need to move the whole predicate matchers bit over to Spec::Matchers to get it to work. This is now on the radar but not first priority. If you can figure out how to do that, feel free to submit another patch. Otherwise, we'll get to it eventually. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-09-13 06:16 Message: Please post your .autotest file so I can see this in action. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13759&group_id=797 From noreply at rubyforge.org Sun Sep 16 04:05:19 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 16 Sep 2007 04:05:19 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-13907 ] Would like "exist" to be in Spec::Matchers (like the others) Message-ID: <20070916080519.8B0F25240DA4@rubyforge.org> Patches item #13907, was opened at 2007-09-13 20:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13907&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Bret Pettichord (bret) Assigned to: Nobody (None) >Summary: Would like "exist" to be in Spec::Matchers (like the others) Initial Comment: I had submitted a patch http://rubyforge.org/tracker/?func=detail&group_id=797&aid=10473&atid=3152, but it was refactored in a way that reduced its scope. Specifically, I would like "should exist" to work in any class that includes Spec::Matchers, not just the it-blocks. Attached please find an additional test that fails with the current version of Rspec (as well as prior versions), but passes with my originally submitted implementation of "exist". For convenience, i have included that implementation in this test, so that the test actually passes if you apply the patch. To reproduced the failure, you'll have to remove this added class. The right solution is probably more complicated, but i never quite understood how my original solution was refactored, so i'm not sure what the best solution would be. Thank you for your consideration. With Watir, we regularly extract test code out of the specs, and therefore this ability is valuable to us. We have not seen this problem with the other methods in Spec::Matchers. Bret Index: C:/work/rspec-rspec/spec/spec/matchers/exist_spec.rb =================================================================== --- C:/work/rspec-rspec/spec/spec/matchers/exist_spec.rb (revision 2561) +++ C:/work/rspec-rspec/spec/spec/matchers/exist_spec.rb (working copy) @@ -45,4 +45,47 @@ should fail end end + +# Additional Test +module Spec + module Matchers + class Exist + def matches? actual + @actual = actual + @actual.exist? + end + def failure_message + "expected #{@actual.inspect} to exist, but it doesn't." + end + def negative_failure_message + "expected #{@actual.inspect} to not exist, but it does." + end + end + def exist; Exist.new; end + end +end + +class SubstanceTester + include Spec::Matchers + def initialize substance + @substance = substance + end + def assert_exists + @substance.should exist + end +end + +describe "should exist, outside of a behavior" do + before(:each) do + @real = Substance.new true, 'something real' + @imaginary = Substance.new false, 'something imaginary' + end + it "should still pass if target exists" do + real_tester = SubstanceTester.new @real + real_tester.assert_exists + end +end + + + ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-16 08:05 Message: I added the failing example to r2566 (set to pending). We got rid of the matcher when we added a default set of predicate matchers that included exist. We only added that to the ExampleApi, so we'd need to move the whole predicate matchers bit over to Spec::Matchers to get it to work. This is now on the radar but not first priority. If you can figure out how to do that, feel free to submit another patch. Otherwise, we'll get to it eventually. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13907&group_id=797 From noreply at rubyforge.org Sun Sep 16 06:56:14 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 16 Sep 2007 06:56:14 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-13913 ] Scenario should treat no code block as & quot; pending& quot; Message-ID: <20070916105614.B14825240BC3@rubyforge.org> Feature Requests item #13913, was opened at 2007-09-13 23:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13913&group_id=797 Category: Story Runner Group: None Status: Open Priority: 3 Submitted By: Evan Light (sleight42) Assigned to: Nobody (None) Summary: Scenario should treat no code block as &quot;pending&quot; Initial Comment: Currently, Scenario errors out when not supplied a body. It should behave similarly to "describe/it" where "it" is not required to have a code block. When a code block is not given, it is treated as pending. This could also be extended to Given/Then/When. Ultmately, this would have the benefit of allowing one to effectively document the entire User Story without having to furnish any code -- but still allowing Story Runner to generate documentation for it. I'll see about supplying a patch this evening ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-16 10:56 Message: The steps DO care whether they get a block, but they don't necessarily raise errors when they don't. Essentially, the first time a specific string is passed to a step it has to have a block - and that block gets mapped to that string in a hash. The next time that string is used without a block, it uses the previously defined block: Given "foo with", 1 do |arg| puts arg end Given "foo with", 2 => ... Given foo with 1 ... Given foo with 2 ---------------------------------------------------------------------- Comment By: Evan Light (sleight42) Date: 2007-09-14 03:39 Message: Incidentally, from perusing the code a little more, it looks like Given/When/Then probably don't care whether they are given code blocks. Haven't dug into this too much yet. Was more interested in Scenario behavior first. ---------------------------------------------------------------------- Comment By: Evan Light (sleight42) Date: 2007-09-14 03:37 Message: Patch attached. Depends upons a previous "bugfix" to the test code that I reported and patched earlier. Redundant as it is included in this patch ("exception_from"). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13913&group_id=797 From undees at gmail.com Sun Sep 16 14:01:17 2007 From: undees at gmail.com (Ian Dees) Date: Sun, 16 Sep 2007 11:01:17 -0700 Subject: [rspec-devel] rspec extensions Message-ID: Hi, all. Quoth Brian: > I think such a tagging feature would be useful in rspec core. To add > it to rspec core (trunk), I think the following objects need to be > touched (without seeing the code): > * Tagging object(s) > * Example.suite > * ExampleApi (describe, it, and tags methods) > * ExampleDefinition (tags method) > * Options (For non-rake command line arguments) > * OptionParser (For non-rake command line arguments) > * maybe SpecTask This to-do list sounds similar to the objects we had to modify or at least study for a similar project at work. We've hacked a tagging-like option by using custom formatters that take parameters, something like: spec --format tag:foo --format tag:bar baz_spec.rb I think we mainly had to mess around with the parser because we're calling RSpec from our own command-line tool. We use it for batch vs. interactive tests (a couple of our tests require physically connecting a calibration cable or grabbing a printout from the printer), and we want to use it for English vs. non-language-specific tests. We could get rid of all our custom formatter cruft (and option parsing cruft) if we had tags. Our code is a little baroque now. (If I had it all to do over again, I would've used the -r option and just had my setup in different .rb files.) But with every release of RSpec, I seem to be able to cut a few more kludges from my stuff -- the trend is definitely going in the right direction. How would a tags mechanism be different from the behaviour_type option that Aslak mentioned? Is there documentation on behaviour_type? I see a few examples of how to attach it to a "describe" block, but not much on what to do with it after that. --Ian From noreply at rubyforge.org Sun Sep 16 15:08:21 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 16 Sep 2007 15:08:21 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-13708 ] Revision 2482 killed custom assertions in spec:ui Message-ID: <20070916190821.143C75240CDA@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: Accepted Priority: 3 Submitted By: Marcus Ahnve (mahnve) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Revision 2482 killed custom assertions in spec:ui Initial Comment: Rev 2482 did something that takes our custom expectations for Selenium using spec:ui out of the call chain - they are no longer called at all. In revision 2481 this works. I've tried running the Watir examples, which custom expectations we basically copied, and they seem broken too. I am trying to locate what in that rev that causes this to happen, but I have so far been unsuccessful. ---------------------------------------------------------------------- >Comment By: Marcus Ahnve (mahnve) Date: 2007-09-16 21:08 Message: Did you mean that the other RFE wanted *rails* matchers available everywhere? Your proposed solution sounds like a good compromise. Would it include stories/ as well? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-09-13 08:42 Message: Ah yes - this was a fix to another RFE that wanted the rspec matchers available everywhere under spec. Need to think about how I want to approach this. Probably undo the other feature so you get rails goodies for free in spec/models, spec/views, spec/controllers, spec/helpers, and spec/lib, but anywhere else you have explicitly say :behaviour_type => :rails. WDYT? ---------------------------------------------------------------------- Comment By: Marcus Ahnve (mahnve) Date: 2007-09-06 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 Sun Sep 16 15:12:38 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 16 Sep 2007 15:12:38 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-13708 ] Revision 2482 killed custom assertions in spec:ui Message-ID: <20070916191238.CF3DA5240CED@rubyforge.org> Bugs item #13708, was opened at 2007-09-06 08:16 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13708&group_id=797 Category: None Group: None Status: Open Resolution: Accepted Priority: 3 Submitted By: Marcus Ahnve (mahnve) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Revision 2482 killed custom assertions in spec:ui Initial Comment: Rev 2482 did something that takes our custom expectations for Selenium using spec:ui out of the call chain - they are no longer called at all. In revision 2481 this works. I've tried running the Watir examples, which custom expectations we basically copied, and they seem broken too. I am trying to locate what in that rev that causes this to happen, but I have so far been unsuccessful. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-16 19:12 Message: Rails matchers everywhere under the spec directory on a Rails project, yes. It even sounds reasonable, but obviously presents us with this problem. re: Stories. 2 things: 1 - stories are going to live under RAILS_ROOT/stories, not RAILS_ROOT/specs. 2 - they wrap rails IntegrationTest, so they DO include the Rails matchers. Cheers, David ---------------------------------------------------------------------- Comment By: Marcus Ahnve (mahnve) Date: 2007-09-16 19:08 Message: Did you mean that the other RFE wanted *rails* matchers available everywhere? Your proposed solution sounds like a good compromise. Would it include stories/ as well? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-09-13 06:42 Message: Ah yes - this was a fix to another RFE that wanted the rspec matchers available everywhere under spec. Need to think about how I want to approach this. Probably undo the other feature so you get rails goodies for free in spec/models, spec/views, spec/controllers, spec/helpers, and spec/lib, but anywhere else you have explicitly say :behaviour_type => :rails. WDYT? ---------------------------------------------------------------------- Comment By: Marcus Ahnve (mahnve) Date: 2007-09-06 08:39 Message: I found the line causing this to happen: In rspec_on_rails/lib/spec/rails/dsl/behaviour/rails_example.rb, the line Spec::DSL::BehaviourFactory.add_behaviour_class(:default, self) does something that reoverrides our custom expectations. The problem seems to be that the rspec_on_rails expectations by the call above are defined after our custom definitions. It therefore only affects our own "have_tag" etc, which have a expectation with the same name in RSpec On Rails. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13708&group_id=797 From noreply at rubyforge.org Sun Sep 16 16:07:14 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 16 Sep 2007 16:07:14 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-13708 ] Revision 2482 killed custom assertions in spec:ui Message-ID: <20070916200714.D1AA45240C09@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: Accepted Priority: 3 Submitted By: Marcus Ahnve (mahnve) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Revision 2482 killed custom assertions in spec:ui Initial Comment: Rev 2482 did something that takes our custom expectations for Selenium using spec:ui out of the call chain - they are no longer called at all. In revision 2481 this works. I've tried running the Watir examples, which custom expectations we basically copied, and they seem broken too. I am trying to locate what in that rev that causes this to happen, but I have so far been unsuccessful. ---------------------------------------------------------------------- >Comment By: Marcus Ahnve (mahnve) Date: 2007-09-16 22:07 Message: Ah yes. I was only thinking of stories mapping to integration tests - but they are currently declared as such. Your original proposal is probably good. But I just remembered that our spec:ui specs are in a separate spec_ui folder, and not under the spec folder. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-09-16 21:12 Message: Rails matchers everywhere under the spec directory on a Rails project, yes. It even sounds reasonable, but obviously presents us with this problem. re: Stories. 2 things: 1 - stories are going to live under RAILS_ROOT/stories, not RAILS_ROOT/specs. 2 - they wrap rails IntegrationTest, so they DO include the Rails matchers. Cheers, David ---------------------------------------------------------------------- Comment By: Marcus Ahnve (mahnve) Date: 2007-09-16 21:08 Message: Did you mean that the other RFE wanted *rails* matchers available everywhere? Your proposed solution sounds like a good compromise. Would it include stories/ as well? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-09-13 08:42 Message: Ah yes - this was a fix to another RFE that wanted the rspec matchers available everywhere under spec. Need to think about how I want to approach this. Probably undo the other feature so you get rails goodies for free in spec/models, spec/views, spec/controllers, spec/helpers, and spec/lib, but anywhere else you have explicitly say :behaviour_type => :rails. WDYT? ---------------------------------------------------------------------- Comment By: Marcus Ahnve (mahnve) Date: 2007-09-06 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 Mon Sep 17 12:09:48 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 17 Sep 2007 12:09:48 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-13943 ] ProfileFormatter (Top 10 slowest examples) Message-ID: <20070917160948.DA7A35240BC4@rubyforge.org> Patches item #13943, was opened at 2007-09-14 21:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13943&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Ian Leitch (idl) Assigned to: Nobody (None) Summary: ProfileFormatter (Top 10 slowest examples) Initial Comment: At work we have roughly 1600 examples, and they take about 45 seconds to run; a bit too long. Upgrading from 1.0.5 to 1.0.8 actually almost doubled the time it takes for our specs to run, though I haven't had the time to investigate what particular change (s) introduced the new overhead. In an attempt to improve this situation, I've created a simple formatter (attached) that times each example and produces a list of the 10 slowest. It turns out that our slowest examples are in the 0.4 seconds range, way too slow for a single example. Unsurprisingly, most of them are Rails view specs, and I suspect the rendering and response body parsing is to blame here. I plan to investigate this further down the stack and see if there is any low hanging fruit to be had. Cheers Ian Leitch ---------------------------------------------------------------------- >Comment By: Ian Leitch (idl) Date: 2007-09-17 16:09 Message: What do you guys think about committing this, anything you want changing? ---------------------------------------------------------------------- Comment By: Ian Leitch (idl) Date: 2007-09-15 08:47 Message: It extends ProgressBarFormatter just to give the user some indication of progress while it's running. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-09-15 03:26 Message: Very nice. A small comment - why is it extending ProgressBarFormatter? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13943&group_id=797 From noreply at rubyforge.org Mon Sep 17 12:45:24 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 17 Sep 2007 12:45:24 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10465 ] Pre_commit method comments Message-ID: <20070917164524.C86D15240C7A@rubyforge.org> Patches item #10465, was opened at 2007-04-30 14:53 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10465&group_id=797 Category: build Group: None >Status: Deleted Resolution: None Priority: 3 Submitted By: Antti Tarvainen (tarvaina) Assigned to: Nobody (None) Summary: Pre_commit method comments Initial Comment: As the first step to refactor the pre_commit code I reviewed it and added comments to reveal its (perceived) intention and tricky places of implementation. I didn't make any changes to the code but I did write some FIXMEs to wherever I noticed dead code or bugs. I plan to remove most of the comments after the specs and the code itself reveal intention better. BTW. Should we have a build category or something similar in the RubyForge tracker? This doesn't fall under any of the existing categories. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-03 13:19 Message: I added a documentation category but failed to set it to public when I did and there is rubyforge bug that won't allow a private tracker to become public. I've got an open RFE w/ the rubyforge project on this. Though inline comments in the code that are in place as part of a refactoring should not go in a documentation tracker. That would be specifically for website and rdoc. ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-05-03 09:24 Message: Shouldn't we also have a documentation category? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-04-30 15:35 Message: Added build category and set this accordingly. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10465&group_id=797 From noreply at rubyforge.org Mon Sep 17 12:45:41 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 17 Sep 2007 12:45:41 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-10574 ] Pre_commit refactoring Message-ID: <20070917164544.6A352A970013@rubyforge.org> Patches item #10574, was opened at 2007-05-04 17:25 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10574&group_id=797 Category: None Group: None >Status: Deleted Resolution: None Priority: 3 Submitted By: Antti Tarvainen (tarvaina) Assigned to: Nobody (None) Summary: Pre_commit refactoring Initial Comment: Here's a refactoring of the rails plugin part of the pre_commit code. Since it's a lot of code, you might want to try it out for a couple of days before you decide if it should be committed to the trunk. The code is fully specced, but the specs don't run as part of the pre_commit procedure yet. To run them, run rake in new_pre_commit directory. I tried to change the functionality as little as possible. However, a few things did change. Most notably: * The output is a little different. * The current Rails edge succeeds on the old pre_commit, but fails on the new one. The new pre_commit doesn't tolerate the config.breakpoint_server deprecation warning. The old pre_commit tries to guess from the script/generate output, which lines are errors and which are not. The new pre_commit uses script/generate --quiet and assumes any output is an error message. Other things: * The code still uses SVN export and revert, so pre_commit fails if you try to run it on svn-exported code rather than svn-checked-out. * I have only run the code on Mac. If someone wants to test it on Windows, that would be great. You will probably need the win32-popen.gem to run it, though. I probably won't have any time next week, but I plan to refactor the rest of the pre_commit code the week after. If someone else wants to do it before that, that's fine also. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-27 12:53 Message: Much better. Thanks. Kinda swamped right now but one of us will look at this soon. Cheers, David ---------------------------------------------------------------------- Comment By: Antti Tarvainen (tarvaina) Date: 2007-05-27 12:46 Message: Here's an updated version of the patch. Changes: - It's a real diff (the old patch was also a diff, but in a parallel directory structure, so you couldn't see what was removed). - Doesn't support Rails 1.1.6 anymore. - Uses rspec_scaffold instead of rspec_resource. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-27 05:41 Message: Antti - can you resubmit this as a diff? I want to be able to see what you're actually changing. ---------------------------------------------------------------------- Comment By: Antti Tarvainen (tarvaina) Date: 2007-05-10 17:24 Message: The purpose is to add specs to it so that we know that we don't break it when we change it. In the original form, it was too complicated to spec in a reasonable manner. For an example of the type of problems that can go unnoticed without specs, see patch 10315. http://rubyforge.org/tracker/index.php?func=detail&aid=10315&group_id=797&atid=3151 In my opinion, although it is "just" the build code it should not be left unspecced. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-10 15:35 Message: What's the purpose of this refactoring? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-04 17:37 Message: Just a quick heads up before I look at this. I just removed the call to config.breakpoint_server, so that shouldn't be an issue any more. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=10574&group_id=797 From noreply at rubyforge.org Mon Sep 17 17:57:13 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 17 Sep 2007 17:57:13 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-13913 ] Scenario should treat no code block as & amp; quot; pending& amp; quot; Message-ID: <20070917215713.2C36D5240B88@rubyforge.org> Feature Requests item #13913, was opened at 2007-09-13 19:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13913&group_id=797 Category: Story Runner Group: None Status: Open Priority: 3 Submitted By: Evan Light (sleight42) Assigned to: Nobody (None) >Summary: Scenario should treat no code block as &amp;quot;pending&amp;quot; Initial Comment: Currently, Scenario errors out when not supplied a body. It should behave similarly to "describe/it" where "it" is not required to have a code block. When a code block is not given, it is treated as pending. This could also be extended to Given/Then/When. Ultmately, this would have the benefit of allowing one to effectively document the entire User Story without having to furnish any code -- but still allowing Story Runner to generate documentation for it. I'll see about supplying a patch this evening ---------------------------------------------------------------------- >Comment By: Evan Light (sleight42) Date: 2007-09-17 17:57 Message: I should've caveated here that I haven't looked at the code for Given/When/Then/And yet. Clearly, I need to be mindful not to make such broad remarks when my knowledge is limited to a subset. ;) My apologies. May I suggest that the scope of this patch be limited to simply the Story and Scenario classes as submitted in my patch? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-09-16 06:56 Message: The steps DO care whether they get a block, but they don't necessarily raise errors when they don't. Essentially, the first time a specific string is passed to a step it has to have a block - and that block gets mapped to that string in a hash. The next time that string is used without a block, it uses the previously defined block: Given "foo with", 1 do |arg| puts arg end Given "foo with", 2 => ... Given foo with 1 ... Given foo with 2 ---------------------------------------------------------------------- Comment By: Evan Light (sleight42) Date: 2007-09-13 23:39 Message: Incidentally, from perusing the code a little more, it looks like Given/When/Then probably don't care whether they are given code blocks. Haven't dug into this too much yet. Was more interested in Scenario behavior first. ---------------------------------------------------------------------- Comment By: Evan Light (sleight42) Date: 2007-09-13 23:37 Message: Patch attached. Depends upons a previous "bugfix" to the test code that I reported and patched earlier. Redundant as it is included in this patch ("exception_from"). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13913&group_id=797 From noreply at rubyforge.org Mon Sep 17 18:22:34 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 17 Sep 2007 18:22:34 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-14023 ] Small optimization for heavily proxied objects. Message-ID: <20070917222235.064895240E31@rubyforge.org> Patches item #14023, was opened at 2007-09-17 22:22 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14023&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Ian Leitch (idl) Assigned to: Nobody (None) Summary: Small optimization for heavily proxied objects. Initial Comment: This patch provides roughly a 2% speed-up for my test suite. In situations where objects are heavily proxied it should help more. By the way, this isn't the level of optimization I hope to contribute in the future, I simply stumbled across it when reading the source to create my earlier optimization patch. Cheers Ian Leitch ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14023&group_id=797 From noreply at rubyforge.org Mon Sep 17 18:30:04 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 17 Sep 2007 18:30:04 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-13759 ] rails_rspec overwrites test mappings added in .autotest Message-ID: <20070917223005.00BA15240E58@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. ---------------------------------------------------------------------- >Comment By: Geoffrey Wiseman (diathesis) Date: 2007-09-17 22:30 Message: This is the bit I used: module Autotest::AdditionalSpecs Autotest.add_hook :initialize do |at| at.test_mappings[ %r%^spec/acceptance/.*rb$% ] = proc do |filename| return filename end puts "Mappings @ .autotest:" at.test_mappings.each do |k,v| puts " #{k} => #{v}" end end end When I ran this, I could see it being added in .autotest, but then when rails_rspec.rb ran, if I printed them out in there, it would show that it had overwritten the original values (as of the version i'm on, anyway). ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-09-16 08:04 Message: Disregard that last message - wrong ticket. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-09-16 08:02 Message: I added the failing example to r2566 (set to pending). We got rid of the matcher when we added a default set of predicate matchers that included exist. We only added that to the ExampleApi, so we'd need to move the whole predicate matchers bit over to Spec::Matchers to get it to work. This is now on the radar but not first priority. If you can figure out how to do that, feel free to submit another patch. Otherwise, we'll get to it eventually. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-09-13 06:16 Message: Please post your .autotest file so I can see this in action. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13759&group_id=797 From noreply at rubyforge.org Tue Sep 18 00:49:31 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 18 Sep 2007 00:49:31 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-14030 ] Filenames contain Windows-incompatible characters Message-ID: <20070918044931.9CB505240EA2@rubyforge.org> Bugs item #14030, was opened at 2007-09-18 00:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=14030&group_id=797 Category: RSpec.tmbundle Group: None Status: Open Resolution: None Priority: 3 Submitted By: Chris Gahan (epitron) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Filenames contain Windows-incompatible characters Initial Comment: Since the release of e-Texteditor, Windows users can use Textmate bundles. Unfortunately, the Rspec tmbundle has filenames with :'s in them (which makes windows cry). The culprits are here: http://rspec.rubyforge.org/svn/trunk/RSpec.tmbundle/Preferences/ If it doesn't cramp your style too much, it would be nice to change that. :D ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=14030&group_id=797 From bryansray at gmail.com Mon Sep 17 02:00:58 2007 From: bryansray at gmail.com (Bryan Ray) Date: Mon, 17 Sep 2007 01:00:58 -0500 Subject: [rspec-devel] Nested Resources and Views Message-ID: <29a0119e0709162300odc20077n7e7102cc67a14a24@mail.gmail.com> I'm trying to figure out how to pass in the extra "parameters" to a nested resource inside a view spec. What I have: "departments" is a nested resource inside "portals" URL looks like: /portals/:portal_id/departments Error I'm getting: department_url failed to generate from { :controller => "departments", :action => "show", :portal_id => nil .... I think my question is ... How do I pass in the :portal_id to the render method inside the view. Because right now it's just nil. I've found how to do it inside the controller using the get method ... but nothing about a view. Any feedback would be much appreciated. -- Bryan Ray http://www.bryanray.net "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning." -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070917/27eb5e55/attachment-0001.html From dchelimsky at gmail.com Tue Sep 18 03:37:14 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 18 Sep 2007 09:37:14 +0200 Subject: [rspec-devel] Nested Resources and Views In-Reply-To: <29a0119e0709162300odc20077n7e7102cc67a14a24@mail.gmail.com> References: <29a0119e0709162300odc20077n7e7102cc67a14a24@mail.gmail.com> Message-ID: <57c63afe0709180037q22245ffflac53888ffed5ffe5@mail.gmail.com> On 9/17/07, Bryan Ray wrote: > I'm trying to figure out how to pass in the extra "parameters" to a nested > resource inside a view spec. > > What I have: > "departments" is a nested resource inside "portals" > > URL looks like: > /portals/:portal_id/departments > > Error I'm getting: > department_url failed to generate from { :controller => "departments", > :action => "show", :portal_id => nil .... > > I think my question is ... How do I pass in the :portal_id to the render > method inside the view. Because right now it's just nil. I've found how to > do it inside the controller using the get method ... but nothing about a > view. What does the call to department_url look ilke? > > Any feedback would be much appreciated. > > -- > Bryan Ray > http://www.bryanray.net > > "Programming today is a race between software engineers striving to build > bigger and better idiot-proof programs, and the Universe trying to produce > bigger and better idiots. So far, the Universe is winning." > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From noreply at rubyforge.org Tue Sep 18 05:48:45 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 18 Sep 2007 05:48:45 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-13913 ] Scenario should treat no code block as & amp; quot; pending& amp; quot; Message-ID: <20070918094845.8A33C5240956@rubyforge.org> Feature Requests item #13913, was opened at 2007-09-13 23:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13913&group_id=797 Category: Story Runner Group: None >Status: Closed Priority: 3 Submitted By: Evan Light (sleight42) >Assigned to: David Chelimsky (dchelimsky) Summary: Scenario should treat no code block as &amp;quot;pending&amp;quot; Initial Comment: Currently, Scenario errors out when not supplied a body. It should behave similarly to "describe/it" where "it" is not required to have a code block. When a code block is not given, it is treated as pending. This could also be extended to Given/Then/When. Ultmately, this would have the benefit of allowing one to effectively document the entire User Story without having to furnish any code -- but still allowing Story Runner to generate documentation for it. I'll see about supplying a patch this evening ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-18 09:48 Message: Applied to r2588. ---------------------------------------------------------------------- Comment By: Evan Light (sleight42) Date: 2007-09-17 21:57 Message: I should've caveated here that I haven't looked at the code for Given/When/Then/And yet. Clearly, I need to be mindful not to make such broad remarks when my knowledge is limited to a subset. ;) My apologies. May I suggest that the scope of this patch be limited to simply the Story and Scenario classes as submitted in my patch? ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-09-16 10:56 Message: The steps DO care whether they get a block, but they don't necessarily raise errors when they don't. Essentially, the first time a specific string is passed to a step it has to have a block - and that block gets mapped to that string in a hash. The next time that string is used without a block, it uses the previously defined block: Given "foo with", 1 do |arg| puts arg end Given "foo with", 2 => ... Given foo with 1 ... Given foo with 2 ---------------------------------------------------------------------- Comment By: Evan Light (sleight42) Date: 2007-09-14 03:39 Message: Incidentally, from perusing the code a little more, it looks like Given/When/Then probably don't care whether they are given code blocks. Haven't dug into this too much yet. Was more interested in Scenario behavior first. ---------------------------------------------------------------------- Comment By: Evan Light (sleight42) Date: 2007-09-14 03:37 Message: Patch attached. Depends upons a previous "bugfix" to the test code that I reported and patched earlier. Redundant as it is included in this patch ("exception_from"). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13913&group_id=797 From bryansray at gmail.com Tue Sep 18 09:37:11 2007 From: bryansray at gmail.com (Bryan Ray) Date: Tue, 18 Sep 2007 08:37:11 -0500 Subject: [rspec-devel] Nested Resources and Views In-Reply-To: <57c63afe0709180037q22245ffflac53888ffed5ffe5@mail.gmail.com> References: <29a0119e0709162300odc20077n7e7102cc67a14a24@mail.gmail.com> <57c63afe0709180037q22245ffflac53888ffed5ffe5@mail.gmail.com> Message-ID: <29a0119e0709180637u1698740bj4f698429c58242e8@mail.gmail.com> The department_url looks like: department_url(params[:portal_id], @department) I finally figured it out .... I woke up the next morning and it was just kind of obvious. For the life of me I just couldn't figure out how to pass it the extra parameters. I just had to pass in the params[:portal_id] = "1" in the before (or where ever) and it was happy. Thanks, David. -- Bryan Ray http://www.bryanray.net "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning." On 9/18/07, David Chelimsky wrote: > > On 9/17/07, Bryan Ray wrote: > > I'm trying to figure out how to pass in the extra "parameters" to a > nested > > resource inside a view spec. > > > > What I have: > > "departments" is a nested resource inside "portals" > > > > URL looks like: > > /portals/:portal_id/departments > > > > Error I'm getting: > > department_url failed to generate from { :controller => "departments", > > :action => "show", :portal_id => nil .... > > > > I think my question is ... How do I pass in the :portal_id to the render > > method inside the view. Because right now it's just nil. I've found how > to > > do it inside the controller using the get method ... but nothing about a > > view. > > What does the call to department_url look ilke? > > > > > Any feedback would be much appreciated. > > > > -- > > Bryan Ray > > http://www.bryanray.net > > > > "Programming today is a race between software engineers striving to > build > > bigger and better idiot-proof programs, and the Universe trying to > produce > > bigger and better idiots. So far, the Universe is winning." > > _______________________________________________ > > 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 > -- Bryan Ray http://www.bryanray.net "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning." -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070918/09d20afc/attachment.html From noreply at rubyforge.org Tue Sep 18 11:02:50 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 18 Sep 2007 11:02:50 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-14042 ] Make DRB runner fall back to command line if no DRB server is present Message-ID: <20070918150250.96A955240A49@rubyforge.org> Patches item #14042, was opened at 2007-09-18 10:02 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14042&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Mike Mangino (mmangino) Assigned to: Nobody (None) Summary: Make DRB runner fall back to command line if no DRB server is present Initial Comment: In projects with a CI builder it is nice to have the tests run even without the drb server running. This patches changes the DRB runner to fall back to the command line runner if there is no DRB server running. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14042&group_id=797 From noreply at rubyforge.org Tue Sep 18 11:29:33 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 18 Sep 2007 11:29:33 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-14043 ] Change output ordering to show pending before errors Message-ID: <20070918152933.C9123A97000D@rubyforge.org> Patches item #14043, was opened at 2007-09-18 10:29 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14043&group_id=797 Category: runner module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Mike Mangino (mmangino) Assigned to: Nobody (None) Summary: Change output ordering to show pending before errors Initial Comment: When running via the console, it's much nicer to see errors at the bottom of the screen. If you have a lot of pending specs, you have to scroll to see errors. That makes Red Green Refactor harder to do. This change moves the pending dump from the summary to the reporter object ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14043&group_id=797 From noreply at rubyforge.org Wed Sep 19 17:30:17 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 19 Sep 2007 17:30:17 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-14082 ] [PATCH] allow stubs to yield and return values Message-ID: <20070919213017.E08BB5240B38@rubyforge.org> Patches item #14082, was opened at 2007-09-19 15:30 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14082&group_id=797 Category: mock module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Pat Maddox (pergesu) Assigned to: Nobody (None) Summary: [PATCH] allow stubs to yield and return values Initial Comment: Passing blocks to a builder method is a common pattern. For example: new_workflow = build(:name => "Default") do |w| w.add_step :name => "description" w.add_step :name => "screenshot_selection" w.add_step :name => "preview" end This patch lets you stub a method and specify the object to yield and the object to return. It's just a chained and_yield(foo).and_return(bar) @new_workflow = mock_model(Workflow, :add_step => true) Workflow.stub!(:build).and_yield(@new_workflow).and_return @new_workflow ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14082&group_id=797 From brian.takita at gmail.com Thu Sep 20 00:35:19 2007 From: brian.takita at gmail.com (Brian Takita) Date: Wed, 19 Sep 2007 21:35:19 -0700 Subject: [rspec-devel] rspec extensions In-Reply-To: <82c457760709151120m4574f1b3t5c57f873fff3c33@mail.gmail.com> References: <82c457760709122131j1e00822bv38c4bc954e20abec@mail.gmail.com> <1d7ddd110709150020sbdbe275nb5cd2fa91bf4a713@mail.gmail.com> <82c457760709151120m4574f1b3t5c57f873fff3c33@mail.gmail.com> Message-ID: <1d7ddd110709192135p2d498439m7013afcb159f26e0@mail.gmail.com> On 9/15/07, Nick Kallen wrote: > I can wait for the next release... When is it coming out? Perhaps we can > convince Rob to let you and I pair on this. I'd like to be involved so I get > some credit... ;) Your help would be appreciated :) > > I have a couple use cases for tags, but in general the idea is to be able to > run a smaller subset of tests so that you can check in more frequently. > Obvious partitions include "fast" and "slow" (or as I prefer, "smoke" and > "regression", which is not equivalent to "fast" and "slow"). Less obvious, > but equally valuable, is to partition your test suites by functionality > "verticals". For example, being able to run all accounting-related tests, or > user-related tests, or asset-related tests, etc. Often these "verticals" cut > across files and describe-blocks (at least, in rails, they cut across model, > view, helper, and controller specs--but typically also multiple models are > involved.). > > ---- > > I've also been wondering how hard it would be to make the test runner into a > scheduler. What if we could have four databases: > > application_test_1, application_test_2, etc. > > And have the test runner create 4 Rails environments on the fly and run > tests in parallel across them. Some thoughtworks people have been > parallelizing tests by running them all in individual transactions. The > problem here is that fixtures aren't inserted as transactions so it excludes > fixture-based tests. You can load the fixtures in transactions but since > Transactions involve full-table locks, in effect the tests don't run in > parallel. The "scheduling" approach seems to me more sensible. The only > issue is migrating 4 sep databases which can probably be done very rapidly > by means of schema.rb or a dump from one db to the next. I like your idea of having 4 databases. On Peer to Patent we have had success with having multiple test environments, each having their own database. > > On 9/15/07, Brian Takita wrote: > > On 9/12/07, Nick Kallen wrote: > > > i know you're on vacation but i'd bet you're checking your email: > > Not that often. Ive been able to stay away for the most part :) > > I'm ccing the rspec developer list for more ideas. > > > > > > i want to add an extension to RSpec. I'd like to be able to "tag" it and > > > describe statements. For example: > > > > > > it "should ensure that my checkbook is balanced", :tags => [:smoke, > > > :accounting] do > > > end > > > > > > describe Checkbook, "foobar", :tags => [:fast, :accounting] do > > > end > > > > > > (syntax TBD) > > > > > > I then want a rake task like: > > > > > > rake spec TAGS=(fast and accounting) > > > rake spec TAGS=(regression or user) > > > > > > --- > > > > > > How hard would it be to do something like this? Does Rspec have a plugin > > > framework? > > Thats really interesting. There has been talk about adding tagging to > rspec. > > I really like it. This feature would be particularly useful for mature > > projects where the precheckin tests are reducing productivity by being > > slow. Nick, do you have some other use cases in mind? > > > > rspec is a moving target. The internals in svn trunk are significantly > > different from the current release (1.0.8). > > > > I think such a tagging feature would be useful in rspec core. To add > > it to rspec core (trunk), I think the following objects need to be > > touched (without seeing the code): > > * Tagging object(s) > > * Example.suite > > * ExampleApi (describe, it, and tags methods) > > * ExampleDefinition (tags method) > > * Options (For non-rake command line arguments) > > * OptionParser (For non-rake command line arguments) > > * maybe SpecTask > > > > I suspect, in your case, you only care about rake, so you would not > > need to care about Options and OptionParser. > > > > Is this something that you would like to do really soon or can you > > wait for the next release? > > > > If you want to do it before the next release, the touch points will be > > a little different. > > > > The closest thing to a plugin architure is the a configuration object. > > The tags feature seems like it should be implementable by a plugin but > > now requires vertical changes (across several objects). It seems there > > is some work needed there. > > > > Brian > > > > From brian.takita at gmail.com Thu Sep 20 01:01:11 2007 From: brian.takita at gmail.com (Brian Takita) Date: Wed, 19 Sep 2007 22:01:11 -0700 Subject: [rspec-devel] rspec extensions In-Reply-To: <8d961d900709151431t13e247a3vf7489d084950b754@mail.gmail.com> References: <82c457760709122131j1e00822bv38c4bc954e20abec@mail.gmail.com> <1d7ddd110709150020sbdbe275nb5cd2fa91bf4a713@mail.gmail.com> <82c457760709151120m4574f1b3t5c57f873fff3c33@mail.gmail.com> <8d961d900709151431t13e247a3vf7489d084950b754@mail.gmail.com> Message-ID: <1d7ddd110709192201h59786a27n93445e4d0bc2e84d@mail.gmail.com> On 9/15/07, aslak hellesoy wrote: > I agree that this is a compelling feature, especially for large suites > of slow specs. Java's TestNG has this feature already. > > We alreadt have a mechanism for "tagging" behaviours using > :behaviour_type, and I think we should use the existing mechanism. We > can rename it if need be - TestNG calls it group, but :tag or :tags is > fine too - I like that. Right now, behaviour_type (probably should be renamed to example_type or example_type) sets the superclass of the Example. I don't see how multiple tags can be defined with behaviour_type's current implementation. Perhaps behaviour_type can include modules? > > Aslak > > On 9/15/07, Nick Kallen wrote: > > I can wait for the next release... When is it coming out? Perhaps we can > > convince Rob to let you and I pair on this. I'd like to be involved so I get > > some credit... ;) > > > > I have a couple use cases for tags, but in general the idea is to be able to > > run a smaller subset of tests so that you can check in more frequently. > > Obvious partitions include "fast" and "slow" (or as I prefer, "smoke" and > > "regression", which is not equivalent to "fast" and "slow"). Less obvious, > > but equally valuable, is to partition your test suites by functionality > > "verticals". For example, being able to run all accounting-related tests, or > > user-related tests, or asset-related tests, etc. Often these "verticals" cut > > across files and describe-blocks (at least, in rails, they cut across model, > > view, helper, and controller specs--but typically also multiple models are > > involved.). > > > > ---- > > > > I've also been wondering how hard it would be to make the test runner into a > > scheduler. What if we could have four databases: > > > > application_test_1, application_test_2, etc. > > > > And have the test runner create 4 Rails environments on the fly and run > > tests in parallel across them. Some thoughtworks people have been > > parallelizing tests by running them all in individual transactions. The > > problem here is that fixtures aren't inserted as transactions so it excludes > > fixture-based tests. You can load the fixtures in transactions but since > > Transactions involve full-table locks, in effect the tests don't run in > > parallel. The "scheduling" approach seems to me more sensible. The only > > issue is migrating 4 sep databases which can probably be done very rapidly > > by means of schema.rb or a dump from one db to the next. > > > > On 9/15/07, Brian Takita wrote: > > > On 9/12/07, Nick Kallen wrote: > > > > i know you're on vacation but i'd bet you're checking your email: > > > Not that often. Ive been able to stay away for the most part :) > > > I'm ccing the rspec developer list for more ideas. > > > > > > > > i want to add an extension to RSpec. I'd like to be able to "tag" it and > > > > describe statements. For example: > > > > > > > > it "should ensure that my checkbook is balanced", :tags => [:smoke, > > > > :accounting] do > > > > end > > > > > > > > describe Checkbook, "foobar", :tags => [:fast, :accounting] do > > > > end > > > > > > > > (syntax TBD) > > > > > > > > I then want a rake task like: > > > > > > > > rake spec TAGS=(fast and accounting) > > > > rake spec TAGS=(regression or user) > > > > > > > > --- > > > > > > > > How hard would it be to do something like this? Does Rspec have a plugin > > > > framework? > > > Thats really interesting. There has been talk about adding tagging to > > rspec. > > > I really like it. This feature would be particularly useful for mature > > > projects where the precheckin tests are reducing productivity by being > > > slow. Nick, do you have some other use cases in mind? > > > > > > rspec is a moving target. The internals in svn trunk are significantly > > > different from the current release (1.0.8). > > > > > > I think such a tagging feature would be useful in rspec core. To add > > > it to rspec core (trunk), I think the following objects need to be > > > touched (without seeing the code): > > > * Tagging object(s) > > > * Example.suite > > > * ExampleApi (describe, it, and tags methods) > > > * ExampleDefinition (tags method) > > > * Options (For non-rake command line arguments) > > > * OptionParser (For non-rake command line arguments) > > > * maybe SpecTask > > > > > > I suspect, in your case, you only care about rake, so you would not > > > need to care about Options and OptionParser. > > > > > > Is this something that you would like to do really soon or can you > > > wait for the next release? > > > > > > If you want to do it before the next release, the touch points will be > > > a little different. > > > > > > The closest thing to a plugin architure is the a configuration object. > > > The tags feature seems like it should be implementable by a plugin but > > > now requires vertical changes (across several objects). It seems there > > > is some work needed there. > > > > > > Brian > > > > > > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > From brian.takita at gmail.com Thu Sep 20 01:05:27 2007 From: brian.takita at gmail.com (Brian Takita) Date: Wed, 19 Sep 2007 22:05:27 -0700 Subject: [rspec-devel] rspec extensions In-Reply-To: References: Message-ID: <1d7ddd110709192205n632b8b6t7ba9be531f4895@mail.gmail.com> On 9/16/07, Ian Dees wrote: > Hi, all. Quoth Brian: > > > I think such a tagging feature would be useful in rspec core. To add > > it to rspec core (trunk), I think the following objects need to be > > touched (without seeing the code): > > * Tagging object(s) > > * Example.suite > > * ExampleApi (describe, it, and tags methods) > > * ExampleDefinition (tags method) > > * Options (For non-rake command line arguments) > > * OptionParser (For non-rake command line arguments) > > * maybe SpecTask > > This to-do list sounds similar to the objects we had to modify or at > least study for a similar project at work. We've hacked a > tagging-like option by using custom formatters that take parameters, > something like: > > spec --format tag:foo --format tag:bar baz_spec.rb > > I think we mainly had to mess around with the parser because we're > calling RSpec from our own command-line tool. > > We use it for batch vs. interactive tests (a couple of our tests > require physically connecting a calibration cable or grabbing a > printout from the printer), and we want to use it for English vs. > non-language-specific tests. > > We could get rid of all our custom formatter cruft (and option parsing > cruft) if we had tags. Our code is a little baroque now. (If I had > it all to do over again, I would've used the -r option and just had my > setup in different .rb files.) But with every release of RSpec, I > seem to be able to cut a few more kludges from my stuff -- the trend > is definitely going in the right direction. Great. I hope it continues :) > > How would a tags mechanism be different from the behaviour_type option > that Aslak mentioned? Is there documentation on behaviour_type? I > see a few examples of how to attach it to a "describe" block, but not > much on what to do with it after that. behaviour_type sets the class of the Behaviour. behaviour_type is used in rspec on rails. In the current release, behaviour_type can be set to HelperBehaviour, ViewBehaviour, ModelBehaviour, or ControllerBehaviour. In trunk, behaviour is renamed to example. Right now, behaviour_type only allows one definition. A particular example would need to be able to handle multiple Tags. > > --Ian > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From noreply at rubyforge.org Thu Sep 20 01:54:51 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 20 Sep 2007 01:54:51 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-14095 ] Don't have ./script/generate rspec create previous_failures.txt Message-ID: <20070920055451.E6E495240DD6@rubyforge.org> Patches item #14095, was opened at 2007-09-20 01:54 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14095&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Bryan Helmkamp (brynary) Assigned to: Nobody (None) Summary: Don't have ./script/generate rspec create previous_failures.txt Initial Comment: An implementation for http://rubyforge.org/tracker/index.php?func=detail&aid=13412&group_id=797&atid=3152 . I couldn't figure out how to attach this to the other tracker item. Is that possible? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14095&group_id=797 From noreply at rubyforge.org Thu Sep 20 09:08:56 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 20 Sep 2007 09:08:56 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-13837 ] alias :running, :lambda Message-ID: <20070920130856.DAE795240991@rubyforge.org> Feature Requests item #13837, was opened at 2007-09-11 09:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13837&group_id=797 Category: expectation module Group: None Status: Closed Priority: 3 Submitted By: sudara williams (sudara) Assigned to: David Chelimsky (dchelimsky) Summary: alias :running, :lambda Initial Comment: For everyday Rspec "reads like english" purposes, aliasing lambda as "running" would make for some fun spec writing: running { something_risky }.should raise_error running { Fancy.operation }.should_not change(@simple, :factor) or even running { to_the_bathroom }.should_not change(person, :weight) describe "A clear spec language" do it "should replace generic lowlevel language with intuitive goodies" do running { 5.to_s }.call.should == lambda { 5.to_s }.call end end ---------------------------------------------------------------------- Comment By: Wincent Colaiuta (wincent) Date: 2007-09-20 13:08 Message: I actually quite like this proposal, despite the arguments against it. I think that RSpec is all about readable specs -- that is *the* reason I migrated from Test::Unit -- and that if a programmer can learn what "describe", "it", "should" and "should_not" are for, then he/she will have no trouble remembering that "running" is an alias for "lambda". But I also suspect that if both David and Aslak don't like it then there's not much point in continuing the discussion. ---------------------------------------------------------------------- Comment By: sudara williams (sudara) Date: 2007-09-13 11:26 Message: Double Fuggles! No patronizing is in my heart. "Read something deeper, please" is a simple response to the "It is ruby, alias it yourself," which avoids the real discussion and 95% of what I desire to communicate. The string solution is interesting. How about this: The core reason for the usage of lambda (forcing a different pattern for some Rspec matchers, a confusing metaprogamming trick for noobees, and a break from readability) seems to be the need to run code before and after the code specified in the "it" block. In the case of raise_error, we need to catch exceptions. In the case of should change, we need to grab a value before and after, and then compare those two. How about refactoring the pattern from "User uses lambda and a special matcher. Matcher executes code, calls lambda, executes code, evaluates" to "If the matcher requires before and after code, we callback for it before and after running the matcher" The benefits would be good - improved consistency and dsl, and it would also open up matchers to be more flexible. That being said, I've stared at the Spec::DSL stuff for the last 30 min and don't find myself smart enough to really see how that would work. Maybe it can't. What do you think? Anywho, I'm 150% fine with moving on and accepting the current dsl, I just wanted to voice my suggestion- an opportunity for improvement. I've kicked in maybe 50 hours with Rspec so far, and though it was slow going at the start, I really really really really really like the attitudes and processes that you guys are promoting. I've grown a lot as a developer because of it. Thank you, su ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-09-12 15:59 Message: class String def call eval(self) end end I think that should do it, no? ---------------------------------------------------------------------- Comment By: Jay Levitt (jaylev) Date: 2007-09-12 15:47 Message: Oo, that's pretty too. I understand that lambda is a common Ruby-ism, but at the moment, nothing I do (or expect to do in Rails) needs it -except- for rspec, and I don't like to have to think in metaprogramming mode unless I need to. If the eval method is easy to code, works the same as lambda does today, doesn't create any maintenance nightmares, etc., I'd +1 that.. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-09-12 15:37 Message: "My hope is that you guys can read something deeper in my request" strikes me as patronizing and not very helpful. If you're interested in helping us to learn something that we may be missing, please continue to do so respectfully, by example. As I see it, you would like to see RSpec read even more like English. The complicating factor is that we're really trying to ride a fine line between English and Ruby. The examples are supposed to serve as documentation at both high and low levels. At the high level, we have the strings that allow you to express things at whatever level is appropriate for the audience. If you're spec'ing a class, you can choose terminology that speaks to developers. If you're spec'ing a more high-level behaviour, something you might collaborate with customers on, you can choose domain specific terminology. At the low level, we have code. In the end, that code needs to tell its story to the developer. In fact, it has been argued that sexy little tricks like collection.should be_empty does not serve well as documentation for the developer. I believe that this argument has merit. Early on, we recognized that should_equal, while aesthetically pleasing, also hid the Ruby story, which is that there are several ways to define equality, each with their own semantics and significance. In this case we preferred Ruby over English, supporting methods that align directly to Ruby methods. In terms of lambda, this is definitely a Ruby term. No argument there. The question then becomes a matter of goals. We can talk about aesthetics, but whose aesthetic sense are we serving by using 'running' vs 'lambda'? All of this said, there is another approach that comes closer to something you suggested in a previous comment: Basket.add_apple.should change(@fruit, :count) We can't really support that without getting into continuations (no thank you), and even then I'm not convinced we wouldn't suffer some ugly side effects. That said, we *could* do this: 'Basket.add_apple'.should change('fruit.count') We'd have to eval both strings, which you could argue doesn't help any, but it does read more "ideally." WDYT? ---------------------------------------------------------------------- Comment By: sudara williams (sudara) Date: 2007-09-12 14:08 Message: Yikes! lambda = Ruby Sudara.should alias(:lambda) if Sudara.doesnt_like_it Got it. My hope is that you guys can read something deeper in my request. ---------------------------------------------------------------------- Comment By: Matt Aimonetti (matt_a) Date: 2007-09-12 13:20 Message: I agree with Aslak. lambda is part of the Ruby language, it's well documented and if you are a Ruby developer you surely know and understand what it does. Also, aliases are easy enough to add so it shouldn't be a big deal for you to add your own. ---------------------------------------------------------------------- Comment By: sudara williams (sudara) Date: 2007-09-12 12:39 Message: Awwww.... The only thing lambda screens in my face is "what a terribly unhelpful name!" I'll relax ;) A programmer's love for the obscure is only a variation of human love for the familiar. My point with Rspec: lambda (despite it being a familiar idiom to non-beginners) has a single use in Rspec - to specify a code block that will be run as a part of evaluating a more complex match. In other words, Rspec needs to run some code before and after this block in order to do it's magic. Long story short, my opinion Rspec asks me to hack itself using a technique that just aint readable, making for a heavy feeling. >From a DSL point of view (aka, learning Rspec) there is no real way to differentiate matchers that need it. The More Complicated Ones. Idiomatically, lambda is being used as a helper within Rspec internals. Using it, Rspec can go about wrapping my lambda with some code and then executing it. That is the idiom in place here, and that idiom is much better expressed as "running." After all, this is the DSL we'd really love to have, eh? Basket.add_apple.should change(@fruit, :count Thanks for listening, and I'll walk away from this happy to learn and without expecting um that anything.should change ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-09-12 01:40 Message: I must say I agree with Aslak, because lambda screams in my face *delayed evaluation* The reason I suggested run was that a co-worker (who is new to rspec) suggested it. He comes from Test::Unit and keeps on making this mistake: my_method.should raise_error If the code doesn't raise an error (say it returns nil) - then the error message will read something like the following: NoMethodError: nil.call ... (Obviously here the proc is trying to be called...) So maybe a better error message would work in this case? (ps: What is the internal vs. external DSL conversation?) ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-09-11 22:19 Message: Based on recent conversations re: internal vs external DSL's, I have to go w/ Aslak on this one. It's important that your customers understand the Strings you pass to describe and it. It's important that your fellow programmers understand the code in the block. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-09-11 22:10 Message: -1 While I value readability, I value idioms more. lambda is at ruby's core and it's a common idiom - I don't want an alias for it, but everyone is free to make their own alias. ---------------------------------------------------------------------- Comment By: Jay Levitt (jaylev) Date: 2007-09-11 21:27 Message: "run" doesn't read as English, though... running {this}.should do_that ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-09-11 21:26 Message: How about run { do_something }.should raise_error ? ---------------------------------------------------------------------- Comment By: Jay Levitt (jaylev) Date: 2007-09-11 09:55 Message: +1!! ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13837&group_id=797 From noreply at rubyforge.org Thu Sep 20 13:04:09 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 20 Sep 2007 13:04:09 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-14109 ] RailsStory dies badly when no fixtures present Message-ID: <20070920170409.4D6BB5240DCD@rubyforge.org> Patches item #14109, was opened at 2007-09-20 17:04 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14109&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: James Hughes (jpath) Assigned to: Nobody (None) Summary: RailsStory dies badly when no fixtures present Initial Comment: A story like the following: Story 'Something happens', %{ As a user I want to do something So that something will happen. }, :type => RailsStory do Scenario 'User doing something for first time' do Given 'a user' do @user = User.new end When 'the user makes a request' do post '/some_action', :id => 1 end Then 'something should happen' do end end end will die attempting to post when there are no fixtures present (at least, I think that's what's happening.) It dies at the following line in rails/actionpack/lib/action_controller/integration.rb: self.class.fixture_table_names.each do |table_name| 'self.class' at this point is RailsStory. The attached patch just initializes fixture_table_names to an empty array. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14109&group_id=797 From noreply at rubyforge.org Fri Sep 21 17:04:48 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 21 Sep 2007 17:04:48 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-14140 ] fix for TM when switching to alternate file Message-ID: <20070921210448.D64085240C69@rubyforge.org> Patches item #14140, was opened at 2007-09-21 21:04 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14140&group_id=797 Category: RSpec.tmbundle Group: None Status: Open Resolution: None Priority: 3 Submitted By: Trevor Squires (protocool) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: fix for TM when switching to alternate file Initial Comment: When using textmate's ctrl-shift-downarrow (switch to "Alternate File") command I get exceptions of "undefined method + for NilClass". Note: this *only* happens if the 'alternate file' you are trying to switch to does not exist, and you elect to let TM create it for you. The problem appears to be down to content_for() incorrectly checking the file_type parameter. It looks for 'spec' even though it would seem 'model spec' and 'view spec' are examples of the values it receives. I've attached a patch which corrects this issue for me. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14140&group_id=797 From noreply at rubyforge.org Fri Sep 21 17:57:27 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 21 Sep 2007 17:57:27 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-14142 ] Fix for bug #11602: Nested #have_tag specifications fails on the wrong line number Message-ID: <20070921215727.244065240CDC@rubyforge.org> Patches item #14142, was opened at 2007-09-21 23:57 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14142&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Antti Tarvainen (tarvaina) Assigned to: Nobody (None) Summary: Fix for bug #11602: Nested #have_tag specifications fails on the wrong line number Initial Comment: This patch fixes the bug described at http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11602&group_id=797 I added two new examples to illustrate the limits of the bug fix. Now these two work: #1 reported bug, now fixed response.should have_tag("form[action=test]") { should have_tag("input[type=text][name=other_input]") } #2 also fixed response.should have_tag("form[action=test]") { raise "Failed unexpectedly." } This doesn't work: #3 doesn't work response.should have_tag("form[action=test]") { assert false } I marked the third example "pending" in the specs. I am not sure if we want to support test/unit assertions inside rspec-style expectations. Do we support test/unit assertions elsewhere? What do you think? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14142&group_id=797 From aslak.hellesoy at gmail.com Sat Sep 22 11:09:30 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sat, 22 Sep 2007 17:09:30 +0200 Subject: [rspec-devel] BehaviourRunner and ExampleSuite Message-ID: <8d961d900709220809k76e7cd99i3ee32e02ff7979f9@mail.gmail.com> Hi, I've noticed that BehaviourRunner#prepare is invoked via two different chains: bin/spec -> CommandLine#run -> BehaviourRunner#run -> BehaviourRunner#prepare test/unit/testsuite.rb -> ExampleSute#run -> BehaviourRunner#prepare In one single run, #prepare gets called twice, and returns the second time because of the @already_prepared check. This is all quite confusing to me, and the number of delegators in ExampleSuite makes it even more confusing. Now that we're using Test::Unit's runner it occurs to me that we should get rid of our own "runner" stuff, but there still seems to be a lot of redundancy. The code is plain hard to understand. You who've been involved in the Test::Unit refactoring - are you planning to simplify things more and get rid of our own runner? Aslak From aslak.hellesoy at gmail.com Sat Sep 22 11:26:41 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sat, 22 Sep 2007 17:26:41 +0200 Subject: [rspec-devel] BehaviourRunner and ExampleSuite In-Reply-To: <8d961d900709220809k76e7cd99i3ee32e02ff7979f9@mail.gmail.com> References: <8d961d900709220809k76e7cd99i3ee32e02ff7979f9@mail.gmail.com> Message-ID: <8d961d900709220826x393a8037h552dd3da1337756b@mail.gmail.com> The CHANGELOG says "Behaviour subclasses Test::Unit::TestCase". However, when I look in the code, the only subclass of TestCase is Example. There doesn't seem to be a Behaviour class at all anymore, but there are plenty of variables in the code named 'behaviour' For a long while we have been referring to "it" blocks as "examples", and they correspond to test_* methods in xUnit speak. Further, we used to call the describe blocks "behaviours" and they correspond to Test classes in xUnit speak. But now it looks like an "example" is analogous to a Test class?!?! There are 9 (!) example_* files and it's virtually impossible to tell where responsibilities are. Although I'm against extensive documentation in code explaining how the code works internally (because code should be self documenting) I think we're now at a point where we need to add comments or clean things up bigtime. I'm really confused. On 9/22/07, aslak hellesoy wrote: > Hi, > > I've noticed that BehaviourRunner#prepare is invoked via two different chains: > > bin/spec -> CommandLine#run -> BehaviourRunner#run -> BehaviourRunner#prepare > test/unit/testsuite.rb -> ExampleSute#run -> BehaviourRunner#prepare > > In one single run, #prepare gets called twice, and returns the second > time because of the @already_prepared check. > > This is all quite confusing to me, and the number of delegators in > ExampleSuite makes it even more confusing. Now that we're using > Test::Unit's runner it occurs to me that we should get rid of our own > "runner" stuff, but there still seems to be a lot of redundancy. The > code is plain hard to understand. > > You who've been involved in the Test::Unit refactoring - are you > planning to simplify things more and get rid of our own runner? > > Aslak > From noreply at rubyforge.org Sat Sep 22 14:35:11 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 22 Sep 2007 14:35:11 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-14152 ] Output warning when method is defined on a nil object. Message-ID: <20070922183511.C56BFA970002@rubyforge.org> Patches item #14152, was opened at 2007-09-22 18:35 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14152&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Ian Leitch (idl) Assigned to: Nobody (None) Summary: Output warning when method is defined on a nil object. Initial Comment: This patch causes define_expected_method to output a warning when a method is defined on a nil object. This patch allows me to quickly resolve failing specs caused by typos. e.g.: before do @obj = mock('some object') @ob.stub!(:do_stuff) end it "should do something" do some_trigger end This will result in: Warning: 'do_stuff' defined on a nil object at foo.rb:123. This patch highlights some nil object stubs in the rspec's own specs. Most appear to be where the author hasn't bothered to use the method created in the before block (or not realized they were referencing a nil object). Although, one case identified in passing_mock_argument_constraints_spec.rb is where the "handling non-constraint arguments" behavior does not define 'it_should_behave_like "mock argument constraints"'. Cheers Ian ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14152&group_id=797 From noreply at rubyforge.org Sat Sep 22 15:18:49 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 22 Sep 2007 15:18:49 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-14152 ] Output warning when method is defined on a nil object. Message-ID: <20070922191849.E3C265240BEC@rubyforge.org> Patches item #14152, was opened at 2007-09-22 18:35 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14152&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Ian Leitch (idl) Assigned to: Nobody (None) Summary: Output warning when method is defined on a nil object. Initial Comment: This patch causes define_expected_method to output a warning when a method is defined on a nil object. This patch allows me to quickly resolve failing specs caused by typos. e.g.: before do @obj = mock('some object') @ob.stub!(:do_stuff) end it "should do something" do some_trigger end This will result in: Warning: 'do_stuff' defined on a nil object at foo.rb:123. This patch highlights some nil object stubs in the rspec's own specs. Most appear to be where the author hasn't bothered to use the method created in the before block (or not realized they were referencing a nil object). Although, one case identified in passing_mock_argument_constraints_spec.rb is where the "handling non-constraint arguments" behavior does not define 'it_should_behave_like "mock argument constraints"'. Cheers Ian ---------------------------------------------------------------------- >Comment By: Ian Leitch (idl) Date: 2007-09-22 19:18 Message: By the way, if you accept this patch I'll go ahead and fix all the warnings in rspec's specs. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14152&group_id=797 From noreply at rubyforge.org Sat Sep 22 16:26:57 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 22 Sep 2007 16:26:57 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-14155 ] Edge has removed ActionView::Helpers::JavaScriptMacrosHelper Message-ID: <20070922202657.887635240C61@rubyforge.org> Bugs item #14155, was opened at 2007-09-22 22:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=14155&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Simon Nicholls (simon_nicholls) Assigned to: Nobody (None) Summary: Edge has removed ActionView::Helpers::JavaScriptMacrosHelper Initial Comment: Hi, Can you add "rescue nil" to the behaviour helper.rb "include ActionView::Helpers::JavaScriptMacrosHelper" line? It's gone from edge Rails. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=14155&group_id=797 From noreply at rubyforge.org Sat Sep 22 17:36:13 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 22 Sep 2007 17:36:13 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-14155 ] Edge has removed ActionView::Helpers::JavaScriptMacrosHelper Message-ID: <20070922213613.CE33D5240C7A@rubyforge.org> Bugs item #14155, was opened at 2007-09-22 20:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=14155&group_id=797 Category: None Group: None >Status: Closed >Resolution: Out of Date Priority: 3 Submitted By: Simon Nicholls (simon_nicholls) Assigned to: Nobody (None) Summary: Edge has removed ActionView::Helpers::JavaScriptMacrosHelper Initial Comment: Hi, Can you add "rescue nil" to the behaviour helper.rb "include ActionView::Helpers::JavaScriptMacrosHelper" line? It's gone from edge Rails. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-22 21:36 Message: This is long gone in trunk. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=14155&group_id=797 From noreply at rubyforge.org Sat Sep 22 17:40:15 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 22 Sep 2007 17:40:15 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-14156 ] False positives with should_not Message-ID: <20070922214015.B60625240C8C@rubyforge.org> Patches item #14156, was opened at 2007-09-22 23:40 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14156&group_id=797 Category: expectation module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Antti Tarvainen (tarvaina) Assigned to: Nobody (None) Summary: False positives with should_not Initial Comment: The bug #13760 (False positives with "ob.should eql?(something)" and similar) was fixed on SVN revision #2532, but the symmetrical bug on should_not was not. This patch fixes the bug. In other words, the patch makes @target.should_not eql?("foo") raise an exception. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14156&group_id=797 From dchelimsky at gmail.com Sat Sep 22 18:07:24 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 23 Sep 2007 00:07:24 +0200 Subject: [rspec-devel] BehaviourRunner and ExampleSuite In-Reply-To: <8d961d900709220809k76e7cd99i3ee32e02ff7979f9@mail.gmail.com> References: <8d961d900709220809k76e7cd99i3ee32e02ff7979f9@mail.gmail.com> Message-ID: <57c63afe0709221507p3fa8232aw882117438b923e82@mail.gmail.com> On 9/22/07, aslak hellesoy wrote: > Hi, > > I've noticed that BehaviourRunner#prepare is invoked via two different chains: > > bin/spec -> CommandLine#run -> BehaviourRunner#run -> BehaviourRunner#prepare > test/unit/testsuite.rb -> ExampleSute#run -> BehaviourRunner#prepare > > In one single run, #prepare gets called twice, and returns the second > time because of the @already_prepared check. > > This is all quite confusing to me, and the number of delegators in > ExampleSuite makes it even more confusing. Now that we're using > Test::Unit's runner it occurs to me that we should get rid of our own > "runner" stuff, but there still seems to be a lot of redundancy. The > code is plain hard to understand. > > You who've been involved in the Test::Unit refactoring - are you > planning to simplify things more and get rid of our own runner? "You who've been inolved" has been primarily Brian. I've gone in and tweaked some names here and there to clarify my own understanding, but we definitely need to shine a light on things and get clarity for all of us on where things are vis a vis refactoring towards using test/unit runners, where they are going, and what a finish line looks like. Cheers, David > > Aslak > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From noreply at rubyforge.org Sat Sep 22 18:23:31 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 22 Sep 2007 18:23:31 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-14142 ] Fix for bug #11602: Nested #have_tag specifications fails on the wrong line number Message-ID: <20070922222332.06C7C5240C19@rubyforge.org> Patches item #14142, was opened at 2007-09-21 21:57 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14142&group_id=797 Category: expectation module Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Antti Tarvainen (tarvaina) >Assigned to: David Chelimsky (dchelimsky) Summary: Fix for bug #11602: Nested #have_tag specifications fails on the wrong line number Initial Comment: This patch fixes the bug described at http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11602&group_id=797 I added two new examples to illustrate the limits of the bug fix. Now these two work: #1 reported bug, now fixed response.should have_tag("form[action=test]") { should have_tag("input[type=text][name=other_input]") } #2 also fixed response.should have_tag("form[action=test]") { raise "Failed unexpectedly." } This doesn't work: #3 doesn't work response.should have_tag("form[action=test]") { assert false } I marked the third example "pending" in the specs. I am not sure if we want to support test/unit assertions inside rspec-style expectations. Do we support test/unit assertions elsewhere? What do you think? ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-22 22:23 Message: Applied to r2622. Thanks for nailing this one! I've left the pending example. My instinct is that we don't need to resolve that - but I want to think about it for another minute or two. Cheers, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14142&group_id=797 From brian.takita at gmail.com Sat Sep 22 23:33:25 2007 From: brian.takita at gmail.com (Brian Takita) Date: Sat, 22 Sep 2007 20:33:25 -0700 Subject: [rspec-devel] BehaviourRunner and ExampleSuite In-Reply-To: <8d961d900709220809k76e7cd99i3ee32e02ff7979f9@mail.gmail.com> References: <8d961d900709220809k76e7cd99i3ee32e02ff7979f9@mail.gmail.com> Message-ID: <1d7ddd110709222033o6b9cd287h2c511d55daa498d8@mail.gmail.com> On 9/22/07, aslak hellesoy wrote: > Hi, > > I've noticed that BehaviourRunner#prepare is invoked via two different chains: > > bin/spec -> CommandLine#run -> BehaviourRunner#run -> BehaviourRunner#prepare > test/unit/testsuite.rb -> ExampleSute#run -> BehaviourRunner#prepare Yes, this is an intermediate stage. > > In one single run, #prepare gets called twice, and returns the second > time because of the @already_prepared check. When we get rid of the BehaviourRunner, this issue should go away. > > This is all quite confusing to me, and the number of delegators in > ExampleSuite makes it even more confusing. Now that we're using > Test::Unit's runner it occurs to me that we should get rid of our own > "runner" stuff, but there still seems to be a lot of redundancy. The > code is plain hard to understand. Can you explain the redundancy part? The ExampleSuite is there to act as a bridge to the Test::Unit world. The runner responsibilities of the old Behaviour object was moved to the ExampleSuite object. Would it be easier is the delegators were inlined? I found the delegators easier to work with, because its less verbose and the dependencies on the Example class object (Behaviour) and Options is in one place, instead of spread out everywhere. I find this easier and quicker to refactor because its all in one place. That said, we can move the responsibilities around still. Its not optimal yet. > > You who've been involved in the Test::Unit refactoring - are you > planning to simplify things more and get rid of our own runner? I would like to get rid of the runner, but havn't gotten to that point yet. I think it would be easier if we had a global $rspec_options variable instead of having a $behaviour_runner global variable. That way, the options do not need to be passed everywhere. > > Aslak > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From noreply at rubyforge.org Sat Sep 22 23:56:37 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 22 Sep 2007 23:56:37 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-14109 ] RailsStory dies badly when no fixtures present Message-ID: <20070923035637.9F91C5240D6B@rubyforge.org> Patches item #14109, was opened at 2007-09-20 17:04 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14109&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: James Hughes (jpath) Assigned to: Nobody (None) Summary: RailsStory dies badly when no fixtures present Initial Comment: A story like the following: Story 'Something happens', %{ As a user I want to do something So that something will happen. }, :type => RailsStory do Scenario 'User doing something for first time' do Given 'a user' do @user = User.new end When 'the user makes a request' do post '/some_action', :id => 1 end Then 'something should happen' do end end end will die attempting to post when there are no fixtures present (at least, I think that's what's happening.) It dies at the following line in rails/actionpack/lib/action_controller/integration.rb: self.class.fixture_table_names.each do |table_name| 'self.class' at this point is RailsStory. The attached patch just initializes fixture_table_names to an empty array. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-23 03:56 Message: Please post a real example with a real stack trace. I haven't seen this problem and would like to understand it better before adding anything like this. Cheers, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14109&group_id=797 From brian.takita at gmail.com Sun Sep 23 00:41:49 2007 From: brian.takita at gmail.com (Brian Takita) Date: Sat, 22 Sep 2007 21:41:49 -0700 Subject: [rspec-devel] BehaviourRunner and ExampleSuite In-Reply-To: <8d961d900709220826x393a8037h552dd3da1337756b@mail.gmail.com> References: <8d961d900709220809k76e7cd99i3ee32e02ff7979f9@mail.gmail.com> <8d961d900709220826x393a8037h552dd3da1337756b@mail.gmail.com> Message-ID: <1d7ddd110709222141w63ae5d29xb90d53da9d04cc6a@mail.gmail.com> On 9/22/07, aslak hellesoy wrote: > The CHANGELOG says "Behaviour subclasses Test::Unit::TestCase". > However, when I look in the code, the only subclass of TestCase is > Example. There doesn't seem to be a Behaviour class at all anymore, > but there are plenty of variables in the code named 'behaviour' > > For a long while we have been referring to "it" blocks as "examples", > and they correspond to test_* methods in xUnit speak. Further, we used > to call the describe blocks "behaviours" and they correspond to Test > classes in xUnit speak. > > But now it looks like an "example" is analogous to a Test class?!?! Currently Example is the Example instance and Behaviour is the Example class. There is also a SharedBehaviour, which is a Module. Both the Example Class and SharedBehaviour include ExampleApi. It seems like ExampleApi should be renamed to Behaviour. I think ExampleCallbacks can be merged into ExampleApi. ExampleDefinition is used by both SharedBehaviour and the Example class. Example is the actual instance. It is created from an ExampleDefinition. ExampleFactory probably should be renamed back to BehaviourFactory. What do you think? ExampleMatcher should be renamed back to BehaviourMatcher and ExampleMatcher#example_description and should be removed as it doesn't seem to be used anymore. ExampleRunProxy is used by ExampleSuite run the Example block. ExampleShouldRaiseHandler handles should_raise options. ExampleSuite runs the Examples for the Example class. > > There are 9 (!) example_* files and it's virtually impossible to tell > where responsibilities are. Although I'm against extensive > documentation in code explaining how the code works internally > (because code should be self documenting) I think we're now at a point > where we need to add comments or clean things up bigtime. I think things should be cleaned up to be more understandable. The previous versions of rspec were very difficult to understand too. There were a number of things in the wrong places that have been untangled, and there is still more work to do. Since things are different, this is a great opportunity to see it from the eyes of unfamiliarity and make it easier to grok. > > I'm really confused. > > On 9/22/07, aslak hellesoy wrote: > > Hi, > > > > I've noticed that BehaviourRunner#prepare is invoked via two different chains: > > > > bin/spec -> CommandLine#run -> BehaviourRunner#run -> BehaviourRunner#prepare > > test/unit/testsuite.rb -> ExampleSute#run -> BehaviourRunner#prepare > > > > In one single run, #prepare gets called twice, and returns the second > > time because of the @already_prepared check. > > > > This is all quite confusing to me, and the number of delegators in > > ExampleSuite makes it even more confusing. Now that we're using > > Test::Unit's runner it occurs to me that we should get rid of our own > > "runner" stuff, but there still seems to be a lot of redundancy. The > > code is plain hard to understand. > > > > You who've been involved in the Test::Unit refactoring - are you > > planning to simplify things more and get rid of our own runner? > > > > Aslak > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From noreply at rubyforge.org Sun Sep 23 10:27:55 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 23 Sep 2007 10:27:55 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-14166 ] Cannot build trunk Message-ID: <20070923142755.491195240AD0@rubyforge.org> Bugs item #14166, was opened at 2007-09-23 07:27 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=14166&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Doug Wright (douglasdoright) Assigned to: Nobody (None) Summary: Cannot build trunk Initial Comment: I originally posted this on the rspec users list and David Chelimsky asked that I submit a bug. I really want to experiment with the new "Story Runner" functionality in rspec and I'm having trouble using the trunk. I've tried in both windows and linux environments and have different problems on each. On linux, I execute svn co svn://rubyforge.org/var/svn/rspec/trunk to check out the trunk. This completes successfully, so I try to build the gem. The readme on building says: "check out source from svn://rubyforge.org/var/svn/rspec/trunk. Then do the following: rake gem gem install pkg/rspec-0.x.x.gem (you may have to sudo)" This doesn't work in trunk, so I cd into trunk/rspec and execute rake gem. This fails with: dwright at hendrix:~/trunk/rspec$ rake gem (in /home/dwright/trunk/rspec) mkdir pkg rm -rf pkg/rspec_on_rails mkdir pkg rm -rf pkg/RSpec.tmbundle rake aborted! No such file or directory - ../spec_ui /home/dwright/trunk/rspec/Rakefile:227:in `chdir' (See full trace by running task with --trace) On windows (vista), I can't seem to successfully check out the project. When I execute: svn co svn://rubyforge.org/var/svn/rspec/trunk I get the following error part-way through the checkout: svn: In directory 'trunk\RSpec.tmbundle\Preferences' svn: Can't move 'trunk\RSpec.tmbundle\Preferences\.svn\tmp\Symbol List: Behaviour.tmPreferences.tmp.tmp' to 'trunk\RSpec.tmbundle\Preferences\.svn\tmp\Symbol List: Behaviour.tmPreferences.tmp': The parameter is incorrect. I can't proceed in this case because the checkout won't complete. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=14166&group_id=797 From edvard at majakari.net Sun Sep 23 15:42:08 2007 From: edvard at majakari.net (Edvard Majakari) Date: Sun, 23 Sep 2007 22:42:08 +0300 Subject: [rspec-devel] [ rspec-Bugs-14166 ] Cannot build trunk In-Reply-To: <20070923142755.491195240AD0@rubyforge.org> (sfid-20070923_142758_662635_1D656586) References: <20070923142755.491195240AD0@rubyforge.org> (sfid-20070923_142758_662635_1D656586) Message-ID: <46F6C190.6020609@majakari.net> Doug, > On windows (vista), I can't seem to successfully check out the project. When I execute: > > svn co svn://rubyforge.org/var/svn/rspec/trunk > > I get the following error part-way through the checkout: > > svn: In directory 'trunk\RSpec.tmbundle\Preferences' > svn: Can't move 'trunk\RSpec.tmbundle\Preferences\.svn\tmp\Symbol List: Behaviour.tmPreferences.tmp.tmp' to 'trunk\RSpec.tmbundle\Preferences\.svn\tmp\Symbol List: Behaviour.tmPreferences.tmp': The parameter is incorrect. This bug is present in Windows XP (and my guess is in any Windows version) as well. I think the problem is in colon ':' in the tmp file name - I ran into the exactly same problem in RailsConfEurope when I tried to retrieve the trunk using both command line SVN and TortoiseSvn (using Windows XP, because the wireless network adapter doesn't work in Linux). Sorry, I don't have solution for your problem but just wanted to confirm the bug. Is the offending file mandatory file in SVN, or is it a by-product and as such removable? -- //Ed From noreply at rubyforge.org Sun Sep 23 16:13:00 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 23 Sep 2007 16:13:00 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-14166 ] Cannot build trunk Message-ID: <20070923201300.C5EB65240C8C@rubyforge.org> Bugs item #14166, was opened at 2007-09-23 14:27 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=14166&group_id=797 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Doug Wright (douglasdoright) >Assigned to: David Chelimsky (dchelimsky) Summary: Cannot build trunk Initial Comment: I originally posted this on the rspec users list and David Chelimsky asked that I submit a bug. I really want to experiment with the new "Story Runner" functionality in rspec and I'm having trouble using the trunk. I've tried in both windows and linux environments and have different problems on each. On linux, I execute svn co svn://rubyforge.org/var/svn/rspec/trunk to check out the trunk. This completes successfully, so I try to build the gem. The readme on building says: "check out source from svn://rubyforge.org/var/svn/rspec/trunk. Then do the following: rake gem gem install pkg/rspec-0.x.x.gem (you may have to sudo)" This doesn't work in trunk, so I cd into trunk/rspec and execute rake gem. This fails with: dwright at hendrix:~/trunk/rspec$ rake gem (in /home/dwright/trunk/rspec) mkdir pkg rm -rf pkg/rspec_on_rails mkdir pkg rm -rf pkg/RSpec.tmbundle rake aborted! No such file or directory - ../spec_ui /home/dwright/trunk/rspec/Rakefile:227:in `chdir' (See full trace by running task with --trace) On windows (vista), I can't seem to successfully check out the project. When I execute: svn co svn://rubyforge.org/var/svn/rspec/trunk I get the following error part-way through the checkout: svn: In directory 'trunk\RSpec.tmbundle\Preferences' svn: Can't move 'trunk\RSpec.tmbundle\Preferences\.svn\tmp\Symbol List: Behaviour.tmPreferences.tmp.tmp' to 'trunk\RSpec.tmbundle\Preferences\.svn\tmp\Symbol List: Behaviour.tmPreferences.tmp': The parameter is incorrect. I can't proceed in this case because the checkout won't complete. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-23 20:13 Message: There are two separate issues here - building the gem and checking out on windows. Both are fixed as of r2646. In the future, please put separate issues in separate tickets. Thanks ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=14166&group_id=797 From noreply at rubyforge.org Sun Sep 23 16:13:44 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 23 Sep 2007 16:13:44 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-14030 ] Filenames contain Windows-incompatible characters Message-ID: <20070923201344.AE6245240D19@rubyforge.org> Bugs item #14030, was opened at 2007-09-18 04:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=14030&group_id=797 Category: RSpec.tmbundle Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Chris Gahan (epitron) Assigned to: Aslak Helles?y (aslak_hellesoy) Summary: Filenames contain Windows-incompatible characters Initial Comment: Since the release of e-Texteditor, Windows users can use Textmate bundles. Unfortunately, the Rspec tmbundle has filenames with :'s in them (which makes windows cry). The culprits are here: http://rspec.rubyforge.org/svn/trunk/RSpec.tmbundle/Preferences/ If it doesn't cramp your style too much, it would be nice to change that. :D ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-23 20:13 Message: This got fixed w/ http://rubyforge.org/tracker/?func=detail&atid=3149&aid=14166&group_id=797 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=14030&group_id=797 From noreply at rubyforge.org Sun Sep 23 16:14:59 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 23 Sep 2007 16:14:59 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-13918 ] exception_from incorrectly returns a value when no Error occurs in specs Message-ID: <20070923201459.8E1105240CFA@rubyforge.org> Bugs item #13918, was opened at 2007-09-14 02:00 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13918&group_id=797 Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Evan Light (sleight42) Assigned to: Nobody (None) Summary: exception_from incorrectly returns a value when no Error occurs in specs Initial Comment: In rspec_adapter.rb, if exception_from is invoked with a block that does not result in an Error, it will instead return the result of the called block. Patch attached. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-23 20:14 Message: I believe that you re-submitted this with another patch which was accepted. I'm closing this, but feel free to reopen it if I am wrong. Cheers, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13918&group_id=797 From noreply at rubyforge.org Sun Sep 23 16:17:04 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 23 Sep 2007 16:17:04 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-10529 ] have_tag does not work while assert_select does Message-ID: <20070923201704.4DF5C5240CFA@rubyforge.org> Bugs item #10529, was opened at 2007-05-02 20:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10529&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Out of Date Priority: 3 Submitted By: Jason Roelofs (jameskilton) Assigned to: Nobody (None) Summary: have_tag does not work while assert_select does Initial Comment: I cannot get the development environment setup and thus I cannot run the attached patch against SVN trunk, so if this doesn't die for anyone then I'll check my environment, but this is the exact code that is causing problems in my rails app. Basically, I pass in the exact same options to have_tag as I do to assert_select. assert_select passes perfectly while have_tag fails. My environment: Ruby version 1.8.6 (i386-mswin32) RubyGems version 0.9.2 Rails version 1.2.0 Active Record version 1.14.4 Action Pack version 1.12.5 Action Web Service version 1.1.6 Action Mailer version 1.2.5 Active Support version 1.3.1 Edge Rails revision 6494 Application root C:/Development/AdminPortal Environment development Database adapter mysql ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-23 20:17 Message: This one is old and rusty. Jason, if it's still a problem for you please run the spec w/ --backtrace so we can see more detail and reopen this with the output posted. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-03 15:17 Message: Running the spec with --backtrace and posting the backtrace here might help ---------------------------------------------------------------------- Comment By: Jason Roelofs (jameskilton) Date: 2007-05-03 13:57 Message: So it looks like this is in fact a windows problem. I just ran the tests in two different Rails environments (1.2.3 and Edge 6494) on Linux and they both pass. I'll start delving deeper into what could be the problem when I have time. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-03 01:16 Message: Everything's passing against ruby 1.8.5 and 1.8.6 as well. Aslak and I are both running on Macs, so perhaps this is a win-ruby problem. Is there anybody else who is having this problem on windows? ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-05-03 00:56 Message: I applied and committed the patch (r1892) with one minor modification: describe "have_tag", :behaviour_type => :controller do (This is needed in the plugin's specs because it cannot be inferred from its location) It passes fine for me for Railses (edge r, 1.1.6, 1.2.1, 1.2.2, 1.2.3) and Ruby 1.8.4 (about time I upgrade my Ruby, but I'm lazy) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=10529&group_id=797 From noreply at rubyforge.org Sun Sep 23 16:18:47 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 23 Sep 2007 16:18:47 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11259 ] windows?: autotest suppresses output Message-ID: <20070923201847.B628C5240AFF@rubyforge.org> Bugs item #11259, was opened at 2007-05-31 19:15 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11259&group_id=797 Category: None Group: None >Status: Closed >Resolution: Out of Date Priority: 3 Submitted By: Erik Ostrom (eostrom) Assigned to: Nobody (None) Summary: windows?: autotest suppresses output Initial Comment: When I run rspec under autotest (with the change I noted in 11258), it seems to run okay; it detects specs that should be run anew; it runs them (as evidenced by test.log); but it never, ever shows me any output from the spec runner. Even a test known to fail shows me nothing. If I use rspec without autotest, everything works fine. If I use Test::Unit instead of rspec, autotest shows me the full test runner output. So it must be a problem with the way rspec and autotest interact. (I don't know if this is actually a Windows problem, but it seems plausible.) ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-23 20:18 Message: Erik - never heard back from you on the last comment. I'm closing this. If you have more information to help us understand the problem, please reopen it. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-07-23 12:18 Message: The --colour option on windows requires the win32console gem. Do you have that installed? If not, it would help if you would install it and report the behaviour with and without the --colour option. Thanks, David ---------------------------------------------------------------------- Comment By: Adam Grant (krypticus) Date: 2007-07-11 00:31 Message: Yeah. Same here. I don't get any output from the autotest, except to tell me what it's running. Once I remove --colour from the spec.opts line, I get it working just fine. Windows XP Pro w/SP2 Rspec 1.0.5 (r2081) Rails 1.2.3 Ruby 1.8.6 ZenTest 3.6.0 ---------------------------------------------------------------------- Comment By: Erik Ostrom (eostrom) Date: 2007-06-01 04:44 Message: Another useful piece of information I could have given you, it turns out, is the contents of my spec.opts file, which starts with '--colour'. With that removed, the bug goes away. That's probably good enough for me. In case it'll help track down this problem now or in the future, this is as far as I got: * In run_tests() in autotest.rb, the loop that's supposed to loop over characters in the test command's output gets EOF immediately, i.e., there's apparently no output from the spec script. * In colour() in base_text_formatter.rb, @colour and output_to_tty? are both true, so presumably the colour-formatted string is returned. I don't know what happens to it after it's returned and before it gets output. ---------------------------------------------------------------------- Comment By: Erik Ostrom (eostrom) Date: 2007-06-01 03:46 Message: Sorry, I forgot. I think I've got the latest everything: * Windows XP SP2 * Ruby 1.8.6 * Rails 1.2.3 * RSpec and Spec::Rails r2064 * ZenTest 3.6.0 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-05-31 19:27 Message: Before investigating this we need to know the versions of all relevant software you are using, for example: * OS X 10.4.9 * Ruby 1.8.6 * RSpec 1.8.2 or RSpec trunk r1643 * Spec::Rails 1.8.2 or Spec::Rails tag r1234... * Rails 1.2.3 or Rails edge r5645 * Whatever other relevant software. Without this information it's like solving 1 equation (your question) with 5 unknown variables (the versions). We strongly recommend that you use the latest released version of RSpec, alternatively the subversion trunk (if you're the bleeding edge kind of person). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11259&group_id=797 From noreply at rubyforge.org Sun Sep 23 16:21:10 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 23 Sep 2007 16:21:10 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11602 ] Nested #have_tag specifications fails on the wrong line number Message-ID: <20070923202110.2F1C95240AFF@rubyforge.org> Bugs item #11602, was opened at 2007-06-15 21:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11602&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Fran?ois Beausoleil (fbos) Assigned to: Nobody (None) Summary: Nested #have_tag specifications fails on the wrong line number Initial Comment: Ouch... I just spent two hours on this, to finally find that the bug wasn't what I thought at all... I had the following specification (Rails View): response.should have_tag("a[href$=?]", download_asset_path(@asset)) do with_tag "img[src=?]", download_asset_path(@asset) with_tag "img[width=200]" with_tag "img[height=212]" with_tag "img[alt=?]", @asset.title end RSpec was reporting a spec failure on the first line above. After 2 hours of investigation, test reformulating and all, I finally found that the correction was this: response.should have_tag("a[href$=?]", download_asset_path(@asset)) do with_tag "img[src=?]", download_asset_path(@asset) with_tag "img[width=?]", @asset.height with_tag "img[height=?]", @asset.height with_tag "img[alt=?]", @asset.title end No more errors. And sure enough: with_tag "img[width=?]", @asset.height again reports the failure against the "response.should have_tag" line. This is with RSpec 1.0.4. Bye ! Fran?ois ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-23 20:21 Message: This got fixed in r2622. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-06-16 11:41 Message: Please attach the whole stack trace, both with and without -b. Also, please attach the files so we can see the line numbers. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11602&group_id=797 From noreply at rubyforge.org Sun Sep 23 16:22:46 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 23 Sep 2007 16:22:46 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-11960 ] spec command line complains about multiple format options when only one Message-ID: <20070923202246.AC30D5240B93@rubyforge.org> Bugs item #11960, was opened at 2007-07-02 20:06 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11960&group_id=797 Category: None Group: None >Status: Closed >Resolution: Out of Date Priority: 3 Submitted By: Fran?ois Beausoleil (fbos) Assigned to: Nobody (None) Summary: spec command line complains about multiple format options when only one Initial Comment: $ spec --version RSpec-1.0.5 (r2081) - BDD for Ruby http://rspec.rubyforge.org/ $ spec --format specdoc spec/import_spec.rb /usr/local/lib/ruby/gems/1.8/gems/rspec-1.0.5/lib/spec/runner/options.rb:109:in `parse_format': When using several --format options only one of them can be without a file (RuntimeError) from /usr/local/lib/ruby/gems/1.8/gems/rspec-1.0.5/lib/spec/runner/option_parser.rb:118:in `parse' from /usr/local/lib/ruby/1.8/optparse.rb:1260:in `call' from /usr/local/lib/ruby/1.8/optparse.rb:1260:in `parse_in_order' from /usr/local/lib/ruby/1.8/optparse.rb:1247:in `catch' from /usr/local/lib/ruby/1.8/optparse.rb:1247:in `parse_in_order' from /usr/local/lib/ruby/1.8/optparse.rb:1241:in `order!' from /usr/local/lib/ruby/1.8/optparse.rb:1332:in `permute!' from /usr/local/lib/ruby/1.8/optparse.rb:1353:in `parse!' ... 14 levels... from /usr/local/lib/ruby/gems/1.8/gems/rspec-1.0.5/lib/spec/runner/command_line.rb:14:in `run' from /usr/local/lib/ruby/gems/1.8/gems/rspec-1.0.5/bin/spec:3 from /usr/local/bin/spec:16:in `load' from /usr/local/bin/spec:16 Anything wrong with my install ? Thanks ! Fran?ois ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-23 20:22 Message: I am unable to reproduce this. If this is still a problem, please re-submit. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-07-11 17:52 Message: Fran?ois, are you still seeing this behaviour on the trunk? ---------------------------------------------------------------------- Comment By: Michael Klishin (michaelklishin) Date: 2007-07-11 17:03 Message: Nope, Aslak seems to be right ---------------------------------------------------------------------- Comment By: Michael Klishin (michaelklishin) Date: 2007-07-11 17:00 Message: Seems that regexp in options.rb is missing / symbol. Will back with a patch shortly if so. ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-07-03 07:13 Message: I'm unable to reproduce this. If you look at line 109 and 110 of options.rb (where the error is raised), you'll see that @out_used must be true in order for the error to be raised. @out_used is only set to true on line 110, so it sounds like this is a second pass to parse_format. But I don't see how that could happen. Could you insert some debug statements? Does this happen with RSpec trunk too? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=11960&group_id=797 From noreply at rubyforge.org Sun Sep 23 16:37:22 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 23 Sep 2007 16:37:22 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-14170 ] route_for and params_from internal specs fixed Message-ID: <20070923203722.795F15240AF5@rubyforge.org> Patches item #14170, was opened at 2007-09-23 22:37 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14170&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Antti Tarvainen (tarvaina) Assigned to: Nobody (None) Summary: route_for and params_from internal specs fixed Initial Comment: This patch fixes internal examples regarding custom route speccing with params_from and route_for matchers. There were two problems: 1. The route used by the examples was defined in a wrong place and had no effect. 2. The examples used a wrong route, so they didn't test what they were supposed to. No functional changes, just fixed the examples. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14170&group_id=797 From noreply at rubyforge.org Sun Sep 23 16:45:48 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 23 Sep 2007 16:45:48 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-14170 ] route_for and params_from internal specs fixed Message-ID: <20070923204549.518725240AFF@rubyforge.org> Patches item #14170, was opened at 2007-09-23 20:37 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14170&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Antti Tarvainen (tarvaina) Assigned to: Nobody (None) Summary: route_for and params_from internal specs fixed Initial Comment: This patch fixes internal examples regarding custom route speccing with params_from and route_for matchers. There were two problems: 1. The route used by the examples was defined in a wrong place and had no effect. 2. The examples used a wrong route, so they didn't test what they were supposed to. No functional changes, just fixed the examples. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-23 20:45 Message: Applied r2647. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14170&group_id=797 From noreply at rubyforge.org Sun Sep 23 16:54:50 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 23 Sep 2007 16:54:50 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12703 ] pre_commit task only picks up files after they have been svn added Message-ID: <20070923205450.D54815240AFF@rubyforge.org> Bugs item #12703, was opened at 2007-07-30 21:22 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12703&group_id=797 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Jens Kr?mer (jkraemer) Assigned to: Nobody (None) Summary: pre_commit task only picks up files after they have been svn added Initial Comment: Since pre_commit uses svn export to install rspec and rspec_on_rails into the rails project before running tests, one is required to 'svn add' any new files so they actually are included in the test run. This should at least be mentioned at http://rspec.rubyforge.org/community/contribute.html to save potential contributors some time :-) ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-23 20:54 Message: Added note to contribute.html (will show up after next release). r2648 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12703&group_id=797 From noreply at rubyforge.org Sun Sep 23 16:55:58 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 23 Sep 2007 16:55:58 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-12760 ] Autotest regexp no longer matches new pretty output Message-ID: <20070923205558.431D35240B98@rubyforge.org> Bugs item #12760, was opened at 2007-08-02 01:29 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12760&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jay Levitt (jaylev) Assigned to: Nobody (None) Summary: Autotest regexp no longer matches new pretty output Initial Comment: Aslak changed lib/spec/matchers/operator_matcher.rb in July to be nice and pretty, but lib/autotest/rspec.rb hasn't been updated to match it, so the output from autotest is now just blank lines when a should == expectation fails. describe "it" do it "doesn't work" do 1.should == 2 end end Windows XP SP2 under cygwin ruby 1.8.6 [i386-cygwin] rspec r2189 ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-23 20:55 Message: Is this still a problem? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12760&group_id=797 From noreply at rubyforge.org Sun Sep 23 17:00:41 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 23 Sep 2007 17:00:41 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-13326 ] add a parameter will be more convenient Message-ID: <20070923210041.7985A5240AF5@rubyforge.org> Feature Requests item #13326, was opened at 2007-08-24 09:39 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13326&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: xiaoming lin (linxiaoming) Assigned to: Nobody (None) Summary: add a parameter will be more convenient Initial Comment: Spec::Runner::Formatter::HtmlFormatter class WebTestHtmlFormatter < Spec::Runner::Formatter::HtmlFormatter def extra_failure_content(failure) #print "aaa" #print failure.to_s #@output.puts "HTML source1" @behaviour_red = true move_progress @output.puts "
" @output.puts " abcdefg" end end ... But I want to use the example object in WebTestHtmlFormatter? but I can't accept the example object? Is this a good idea? #####def extra_failure_content(failure,example)#### ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-23 21:00 Message: Moving this over to feature requests. It's not really a bug. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13326&group_id=797 From noreply at rubyforge.org Sun Sep 23 17:08:03 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 23 Sep 2007 17:08:03 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-14170 ] route_for and params_from internal specs fixed Message-ID: <20070923210803.D2A8F5240C60@rubyforge.org> Patches item #14170, was opened at 2007-09-23 22:37 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14170&group_id=797 Category: rails plugin Group: None >Status: Open Resolution: Accepted Priority: 3 Submitted By: Antti Tarvainen (tarvaina) Assigned to: Nobody (None) Summary: route_for and params_from internal specs fixed Initial Comment: This patch fixes internal examples regarding custom route speccing with params_from and route_for matchers. There were two problems: 1. The route used by the examples was defined in a wrong place and had no effect. 2. The examples used a wrong route, so they didn't test what they were supposed to. No functional changes, just fixed the examples. ---------------------------------------------------------------------- >Comment By: Antti Tarvainen (tarvaina) Date: 2007-09-23 23:08 Message: Thanks for the quick response, David. I'm afraid the patch didn't go to the SVN completely. The pre_commit_rails task uses SVN revert to clean up routes.rb after testing each Rails version. Thus, to make changes to routes.rb, you have to commit them without using pre_commit. I did the equivalent tests manually before submitting the patch, but to be sure, you should do 'svn update' and 'rake pre_commit' after commiting the patch. Cheers, Antti T. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-09-23 22:45 Message: Applied r2647. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14170&group_id=797 From noreply at rubyforge.org Sun Sep 23 17:19:54 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 23 Sep 2007 17:19:54 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-14170 ] route_for and params_from internal specs fixed Message-ID: <20070923211954.11ECB5240A51@rubyforge.org> Patches item #14170, was opened at 2007-09-23 20:37 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14170&group_id=797 Category: rails plugin Group: None >Status: Closed Resolution: Accepted Priority: 3 Submitted By: Antti Tarvainen (tarvaina) Assigned to: Nobody (None) Summary: route_for and params_from internal specs fixed Initial Comment: This patch fixes internal examples regarding custom route speccing with params_from and route_for matchers. There were two problems: 1. The route used by the examples was defined in a wrong place and had no effect. 2. The examples used a wrong route, so they didn't test what they were supposed to. No functional changes, just fixed the examples. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-23 21:19 Message: Got it - thanks! ---------------------------------------------------------------------- Comment By: Antti Tarvainen (tarvaina) Date: 2007-09-23 21:08 Message: Thanks for the quick response, David. I'm afraid the patch didn't go to the SVN completely. The pre_commit_rails task uses SVN revert to clean up routes.rb after testing each Rails version. Thus, to make changes to routes.rb, you have to commit them without using pre_commit. I did the equivalent tests manually before submitting the patch, but to be sure, you should do 'svn update' and 'rake pre_commit' after commiting the patch. Cheers, Antti T. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-09-23 20:45 Message: Applied r2647. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14170&group_id=797 From noreply at rubyforge.org Sun Sep 23 17:30:32 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 23 Sep 2007 17:30:32 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-14156 ] False positives with should_not Message-ID: <20070923213032.B36B95240BD0@rubyforge.org> Patches item #14156, was opened at 2007-09-22 21:40 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14156&group_id=797 Category: expectation module Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Antti Tarvainen (tarvaina) Assigned to: Nobody (None) Summary: False positives with should_not Initial Comment: The bug #13760 (False positives with "ob.should eql?(something)" and similar) was fixed on SVN revision #2532, but the symmetrical bug on should_not was not. This patch fixes the bug. In other words, the patch makes @target.should_not eql?("foo") raise an exception. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-23 21:30 Message: Applied to r2650 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14156&group_id=797 From noreply at rubyforge.org Sun Sep 23 18:17:33 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 23 Sep 2007 18:17:33 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-13885 ] be_status methods Message-ID: <20070923221734.0A879A970006@rubyforge.org> Feature Requests item #13885, was opened at 2007-09-13 00:11 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13885&group_id=797 Category: rails plugin Group: None Status: Open Priority: 3 Submitted By: Assaf Arkin (assaf) Assigned to: Nobody (None) Summary: be_status methods Initial Comment: response.should be_successful or response.should be_missing are nice but not enough. In too many cases I'm looking for response codes that are neither 200 nor 404. So how about adding all the status symbols as tests methods? Controller: head :unauthorized Spec: response.should be_unauthorized Controller: head :gone Spec: response.should be_gone And so forth. This code will do it for anything using controller (TestResponse) and integration (CgiResponse) tests: module ActionController # TestResponse for functional, CgiResponse for integration. class AbstractResponse StatusCodes::SYMBOL_TO_STATUS_CODE.each do |symbol, code| define_method("#{symbol}?") { self.response_code == code } unless instance_methods.include?("#{symbol}?") end end end ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-23 22:17 Message: I'll add this if you'll submit it as a patch with specs. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13885&group_id=797 From noreply at rubyforge.org Sun Sep 23 20:49:36 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 23 Sep 2007 20:49:36 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-14171 ] "rake spec" in Rails projects broken in edge rails Message-ID: <20070924004937.19C055240BD0@rubyforge.org> Bugs item #14171, was opened at 2007-09-24 10:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=14171&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Pete Yandell (notahat) Assigned to: Nobody (None) Summary: "rake spec" in Rails projects broken in edge rails Initial Comment: As of this patch to Rails: http://dev.rubyonrails.org/ticket/6673 "rake spec" in a Rails proect (with rspec and rspec_on_rails plugins version 1.0.8) throws: vendor/plugins/rspec_on_rails/lib/spec/rails.rb:20: undefined method `run=' for Test::Unit:Module (NoMethodError) It looks like rspec assumes that test/unit has already been required by Rails, which it no longer is. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=14171&group_id=797 From noreply at rubyforge.org Sun Sep 23 20:58:47 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 23 Sep 2007 20:58:47 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-14171 ] "rake spec" in Rails projects broken in edge rails Message-ID: <20070924005847.954FA5240B93@rubyforge.org> Bugs item #14171, was opened at 2007-09-24 00:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=14171&group_id=797 Category: rails plugin Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Pete Yandell (notahat) Assigned to: Nobody (None) >Summary: "rake spec" in Rails projects broken in edge rails Initial Comment: As of this patch to Rails: http://dev.rubyonrails.org/ticket/6673 "rake spec" in a Rails proect (with rspec and rspec_on_rails plugins version 1.0.8) throws: vendor/plugins/rspec_on_rails/lib/spec/rails.rb:20: undefined method `run=' for Test::Unit:Module (NoMethodError) It looks like rspec assumes that test/unit has already been required by Rails, which it no longer is. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-24 00:58 Message: Magicians though we wish we were, there is simply no way for us to make our already released 1.0.8 keep up with edge rails. If you're using edge rails, then you should be using edge spec, in which case you'll find that all is well. Cheers, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=14171&group_id=797 From noreply at rubyforge.org Sun Sep 23 21:57:35 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 23 Sep 2007 21:57:35 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-13969 ] Spec Failures on Trunk w/ Autotest Message-ID: <20070924015735.A44E15240B98@rubyforge.org> Bugs item #13969, was opened at 2007-09-15 20:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13969&group_id=797 Category: Autotest Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) Assigned to: Nobody (None) Summary: Spec Failures on Trunk w/ Autotest Initial Comment: Spec Failures are occurring when using autotest, but not when using the rake task: (This is occuring in trunk/rspec, at revision 2564): ------------------------------------------------------------------------- escher: autotest loading autotest/rspec /sw/bin/ruby1.8 -S bin/spec spec/spec/dsl/composite_proc_builder_spec.rb spec/spec/translator_spec.rb spec/spec/runner/option_parser_spec.rb spec/spec/dsl/predicate_matcher_spec.rb spec/spec/runner/heckler_spec.rb spec/spec/mocks/partial_mock_using_mocks_directly_spec.rb spec/spec/matchers/matcher_methods_spec.rb spec/spec/story/rspec_adapter.rb spec/spec/mocks/record_messages_spec.rb spec/spec/runner/formatter/failing_behaviours_formatter_spec.rb spec/spec/runner/command_line_spec.rb spec/spec/dsl/configuration_spec.rb spec/spec/runner/extensions/bug_report_10577_spec.rb spec/spec/matchers/operator_matcher_spec.rb spec/spec/matchers/be_spec.rb spec/spec/matchers/be_close_spec.rb spec/spec/runner/test_unit_and_rspec_spec.rb spec/spec/runner/formatter/progress_bar_formatter_spec.rb spec/spec/mocks/multiple_return_value_spec.rb spec/spec/runner/formatter/snippet_extractor_spec.rb spec/spec/package/bin_spec_spec.rb spec/spec/runner/reporter_spec.rb spec/spec/runner_spec.rb spec/spec/mocks/stub_spec.rb spec/spec/matchers/description_generation_spec.rb spec/spec/runner/formatter/html_formatter_spec.rb spec/spec/expectations/fail_with_spec.rb spec/spec/matchers/equal_spec.rb spec/spec/mocks/bug_report_7805_spec.rb spec/spec/runner/spec_parser_spec.rb spec/spec/runner/behaviour_runner_spec.rb spec/autotest/discover_spec.rb spec/spec/story/simple_step_spec.rb spec/spec/runner/quiet_backtrace_tweaker_spec.rb spec/spec/story/runner/scenario_runner_spec.rb spec/spec/runner/formatter/progress_bar_formatter_failure_dump_spec.rb spec/spec/runner/heckle_runner_spec.rb spec/spec/mocks/failing_mock_argument_constraints_spec.rb spec/spec/matchers/satisfy_spec.rb spec/spec/dsl/example_instance_spec.rb spec/spec/story/world_spec.rb spec/spec/story/story_spec.rb spec/spec/mocks/at_most_spec.rb spec/spec/mocks/bug_report_11545_spec.rb spec/spec/mocks/mock_ordering_spec.rb spec/spec/dsl/example_matcher_spec.rb spec/spec/story/given_scenario_spec.rb spec/spec/dsl/example_factory_spec.rb spec/spec/runner/formatter/specdoc_formatter_dry_run_spec.rb spec/spec/mocks/bug_report_10260_spec.rb spec/spec/mocks/precise_counts_spec.rb spec/spec/mocks/at_least_spec.rb spec/spec/story/runner_spec.rb spec/spec/runner/testrunnermediator_spec.rb spec/spec/mocks/bug_report_8302_spec.rb spec/spec/dsl/shared_behaviour_spec.rb spec/spec/mocks/passing_mock_argument_constraints_spec.rb spec/spec/runner/formatter/rdoc_formatter_dry_run_spec.rb spec/spec/story/runner/scenario_collector_spec.rb spec/spec/mocks/argument_expectation_spec.rb spec/spec/runner/options_spec.rb spec/spec/matchers/mock_constraint_matchers_spec.rb spec/spec/mocks/any_number_of_times_spec.rb spec/spec/matchers/has_spec.rb spec/spec/runner/object_ext_spec.rb spec/spec/mocks/options_hash_spec.rb spec/spec/dsl/example_definition_class_spec.rb spec/spec/matchers/respond_to_spec.rb spec/spec/mocks/mock_spec.rb spec/spec/mocks/bug_report_7611_spec.rb spec/spec/mocks/once_counts_spec.rb spec/spec/story/runner/story_runner_spec.rb spec/spec/runner/formatter/progress_bar_formatter_dry_run_spec.rb spec/spec/runner/formatter/specdoc_formatter_spec.rb spec/spec/matchers/handler_spec.rb spec/spec/story/step_mother_spec.rb spec/spec/runner/noisy_backtrace_tweaker_spec.rb spec/spec/matchers/eql_spec.rb spec/spec/matchers/include_spec.rb spec/autotest_helper.rb spec/spec/dsl/example_should_raise_spec.rb spec/rspec_suite.rb spec/spec/dsl/behaviour_description_spec.rb spec/spec/runner/formatter/rdoc_formatter_spec.rb spec/spec/spec_classes.rb spec/autotest/rspec_spec.rb spec/spec/story/reporter/plain_text_reporter_spec.rb spec/spec/story/story_helper.rb spec/spec/mocks/bug_report_8165_spec.rb spec/spec/story/documenter/plain_text_documenter_spec.rb spec/spec/matchers/change_spec.rb spec/spec/runner/execution_context_spec.rb spec/spec/mocks/twice_counts_spec.rb spec/spec/mocks/null_object_mock_spec.rb spec/spec/dsl/example_class_definition_spec.rb spec/spec/matchers/simple_matcher_spec.rb spec/spec/matchers/have_spec.rb spec/spec/matchers/raise_error_spec.rb spec/spec/mocks/mock_space_spec.rb spec/spec/runner/drb_command_line_spec.rb spec/spec/story/builders.rb spec/spec/dsl/example_suite_spec.rb spec/spec/runner/extensions/kernel_spec.rb spec/spec/dsl/example_spec.rb spec/spec/story/extensions_spec.rb spec/spec/dsl/example_definition_spec.rb spec/spec/expectations/differs/default_spec.rb spec/spec/runner/formatter/failing_examples_formatter_spec.rb spec/spec/story/scenario_spec.rb spec/spec/dsl/supports_pending_spec.rb spec/spec/matchers/throw_symbol_spec.rb spec/spec/matchers/match_spec.rb spec/spec/matchers/exist_spec.rb spec/spec/expectations/extensions/object_spec.rb spec/spec/mocks/partial_mock_spec.rb ..........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................P.....................................................................................................................................................................................................................................................................................................................................................P.......PP..................................F..F..........P.............. 1) 'should match(expected) should fail when target (String) matches expected (Regexp)' FAILED expected Spec::Expectations::ExpectationNotMetError, got #> ./spec/spec/matchers/match_spec.rb:9: 2) 'should_not match(expected) should fail when target (String) matches expected (Regexp)' FAILED expected Spec::Expectations::ExpectationNotMetError, got #> ./spec/spec/matchers/match_spec.rb:27: Finished in 5.699199 seconds 1049 examples, 2 failures, 5 pending Pending: a Mock expectation should clear expectations after verify (this fails if you run the file normally, but passes if you comment out the example at 116 or run the file in reverse) Example.suite should return an ExampleSuite with Examples (Not Yet Implemented) Example.class_eval should understand module scoping (Example.new needs to create a class that is evaled) Example.class_eval should allow class variables to be defined (class_eval cannot be used. Only the class definition can be used. This may not be possible.) Object#should should raise error if it receives nil (refactor the should method to handle this) ^CInterrupt a second time to quit ^Cescher: rake spec (in /Users/smt/src/ruby/rspec/trunk/rspec) ...............................................................................................................P.......PP..........................................................................P................................................................................................................................................................................................................................................................................................................................................................................................P............................................................................................................................................................................................................................................................................................................................................................................................................................................... Finished in 9.799042 seconds 1012 examples, 0 failures, 5 pending Pending: Example.suite should return an ExampleSuite with Examples (Not Yet Implemented) Example.class_eval should understand module scoping (Example.new needs to create a class that is evaled) Example.class_eval should allow class variables to be defined (class_eval cannot be used. Only the class definition can be used. This may not be possible.) Object#should should raise error if it receives nil (refactor the should method to handle this) a Mock expectation should clear expectations after verify (this fails if you run the file normally, but passes if you comment out the example at 116 or run the file in reverse) -------------------------------------------------------------------------------- Not sure if this has anything to do with Autotest or not. My suspicion is that it's buggy (rspec, not autotest) code. Let me know if I can do anything to help. ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-24 01:57 Message: Fixed in r2653 ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-09-15 20:57 Message: Oops: Forgot to attach my info: Ruby v. 186 Mac OS X.4.10 (Intel) rspec's trunk autotest, latest gem ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13969&group_id=797 From noreply at rubyforge.org Sun Sep 23 22:13:18 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 23 Sep 2007 22:13:18 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-13969 ] Spec Failures on Trunk w/ Autotest Message-ID: <20070924021318.F1C795240BED@rubyforge.org> Bugs item #13969, was opened at 2007-09-15 20:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13969&group_id=797 Category: Autotest Group: None Status: Closed Resolution: Accepted Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) Assigned to: Nobody (None) Summary: Spec Failures on Trunk w/ Autotest Initial Comment: Spec Failures are occurring when using autotest, but not when using the rake task: (This is occuring in trunk/rspec, at revision 2564): ------------------------------------------------------------------------- escher: autotest loading autotest/rspec /sw/bin/ruby1.8 -S bin/spec spec/spec/dsl/composite_proc_builder_spec.rb spec/spec/translator_spec.rb spec/spec/runner/option_parser_spec.rb spec/spec/dsl/predicate_matcher_spec.rb spec/spec/runner/heckler_spec.rb spec/spec/mocks/partial_mock_using_mocks_directly_spec.rb spec/spec/matchers/matcher_methods_spec.rb spec/spec/story/rspec_adapter.rb spec/spec/mocks/record_messages_spec.rb spec/spec/runner/formatter/failing_behaviours_formatter_spec.rb spec/spec/runner/command_line_spec.rb spec/spec/dsl/configuration_spec.rb spec/spec/runner/extensions/bug_report_10577_spec.rb spec/spec/matchers/operator_matcher_spec.rb spec/spec/matchers/be_spec.rb spec/spec/matchers/be_close_spec.rb spec/spec/runner/test_unit_and_rspec_spec.rb spec/spec/runner/formatter/progress_bar_formatter_spec.rb spec/spec/mocks/multiple_return_value_spec.rb spec/spec/runner/formatter/snippet_extractor_spec.rb spec/spec/package/bin_spec_spec.rb spec/spec/runner/reporter_spec.rb spec/spec/runner_spec.rb spec/spec/mocks/stub_spec.rb spec/spec/matchers/description_generation_spec.rb spec/spec/runner/formatter/html_formatter_spec.rb spec/spec/expectations/fail_with_spec.rb spec/spec/matchers/equal_spec.rb spec/spec/mocks/bug_report_7805_spec.rb spec/spec/runner/spec_parser_spec.rb spec/spec/runner/behaviour_runner_spec.rb spec/autotest/discover_spec.rb spec/spec/story/simple_step_spec.rb spec/spec/runner/quiet_backtrace_tweaker_spec.rb spec/spec/story/runner/scenario_runner_spec.rb spec/spec/runner/formatter/progress_bar_formatter_failure_dump_spec.rb spec/spec/runner/heckle_runner_spec.rb spec/spec/mocks/failing_mock_argument_constraints_spec.rb spec/spec/matchers/satisfy_spec.rb spec/spec/dsl/example_instance_spec.rb spec/spec/story/world_spec.rb spec/spec/story/story_spec.rb spec/spec/mocks/at_most_spec.rb spec/spec/mocks/bug_report_11545_spec.rb spec/spec/mocks/mock_ordering_spec.rb spec/spec/dsl/example_matcher_spec.rb spec/spec/story/given_scenario_spec.rb spec/spec/dsl/example_factory_spec.rb spec/spec/runner/formatter/specdoc_formatter_dry_run_spec.rb spec/spec/mocks/bug_report_10260_spec.rb spec/spec/mocks/precise_counts_spec.rb spec/spec/mocks/at_least_spec.rb spec/spec/story/runner_spec.rb spec/spec/runner/testrunnermediator_spec.rb spec/spec/mocks/bug_report_8302_spec.rb spec/spec/dsl/shared_behaviour_spec.rb spec/spec/mocks/passing_mock_argument_constraints_spec.rb spec/spec/runner/formatter/rdoc_formatter_dry_run_spec.rb spec/spec/story/runner/scenario_collector_spec.rb spec/spec/mocks/argument_expectation_spec.rb spec/spec/runner/options_spec.rb spec/spec/matchers/mock_constraint_matchers_spec.rb spec/spec/mocks/any_number_of_times_spec.rb spec/spec/matchers/has_spec.rb spec/spec/runner/object_ext_spec.rb spec/spec/mocks/options_hash_spec.rb spec/spec/dsl/example_definition_class_spec.rb spec/spec/matchers/respond_to_spec.rb spec/spec/mocks/mock_spec.rb spec/spec/mocks/bug_report_7611_spec.rb spec/spec/mocks/once_counts_spec.rb spec/spec/story/runner/story_runner_spec.rb spec/spec/runner/formatter/progress_bar_formatter_dry_run_spec.rb spec/spec/runner/formatter/specdoc_formatter_spec.rb spec/spec/matchers/handler_spec.rb spec/spec/story/step_mother_spec.rb spec/spec/runner/noisy_backtrace_tweaker_spec.rb spec/spec/matchers/eql_spec.rb spec/spec/matchers/include_spec.rb spec/autotest_helper.rb spec/spec/dsl/example_should_raise_spec.rb spec/rspec_suite.rb spec/spec/dsl/behaviour_description_spec.rb spec/spec/runner/formatter/rdoc_formatter_spec.rb spec/spec/spec_classes.rb spec/autotest/rspec_spec.rb spec/spec/story/reporter/plain_text_reporter_spec.rb spec/spec/story/story_helper.rb spec/spec/mocks/bug_report_8165_spec.rb spec/spec/story/documenter/plain_text_documenter_spec.rb spec/spec/matchers/change_spec.rb spec/spec/runner/execution_context_spec.rb spec/spec/mocks/twice_counts_spec.rb spec/spec/mocks/null_object_mock_spec.rb spec/spec/dsl/example_class_definition_spec.rb spec/spec/matchers/simple_matcher_spec.rb spec/spec/matchers/have_spec.rb spec/spec/matchers/raise_error_spec.rb spec/spec/mocks/mock_space_spec.rb spec/spec/runner/drb_command_line_spec.rb spec/spec/story/builders.rb spec/spec/dsl/example_suite_spec.rb spec/spec/runner/extensions/kernel_spec.rb spec/spec/dsl/example_spec.rb spec/spec/story/extensions_spec.rb spec/spec/dsl/example_definition_spec.rb spec/spec/expectations/differs/default_spec.rb spec/spec/runner/formatter/failing_examples_formatter_spec.rb spec/spec/story/scenario_spec.rb spec/spec/dsl/supports_pending_spec.rb spec/spec/matchers/throw_symbol_spec.rb spec/spec/matchers/match_spec.rb spec/spec/matchers/exist_spec.rb spec/spec/expectations/extensions/object_spec.rb spec/spec/mocks/partial_mock_spec.rb ..........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................P.....................................................................................................................................................................................................................................................................................................................................................P.......PP..................................F..F..........P.............. 1) 'should match(expected) should fail when target (String) matches expected (Regexp)' FAILED expected Spec::Expectations::ExpectationNotMetError, got #> ./spec/spec/matchers/match_spec.rb:9: 2) 'should_not match(expected) should fail when target (String) matches expected (Regexp)' FAILED expected Spec::Expectations::ExpectationNotMetError, got #> ./spec/spec/matchers/match_spec.rb:27: Finished in 5.699199 seconds 1049 examples, 2 failures, 5 pending Pending: a Mock expectation should clear expectations after verify (this fails if you run the file normally, but passes if you comment out the example at 116 or run the file in reverse) Example.suite should return an ExampleSuite with Examples (Not Yet Implemented) Example.class_eval should understand module scoping (Example.new needs to create a class that is evaled) Example.class_eval should allow class variables to be defined (class_eval cannot be used. Only the class definition can be used. This may not be possible.) Object#should should raise error if it receives nil (refactor the should method to handle this) ^CInterrupt a second time to quit ^Cescher: rake spec (in /Users/smt/src/ruby/rspec/trunk/rspec) ...............................................................................................................P.......PP..........................................................................P................................................................................................................................................................................................................................................................................................................................................................................................P............................................................................................................................................................................................................................................................................................................................................................................................................................................... Finished in 9.799042 seconds 1012 examples, 0 failures, 5 pending Pending: Example.suite should return an ExampleSuite with Examples (Not Yet Implemented) Example.class_eval should understand module scoping (Example.new needs to create a class that is evaled) Example.class_eval should allow class variables to be defined (class_eval cannot be used. Only the class definition can be used. This may not be possible.) Object#should should raise error if it receives nil (refactor the should method to handle this) a Mock expectation should clear expectations after verify (this fails if you run the file normally, but passes if you comment out the example at 116 or run the file in reverse) -------------------------------------------------------------------------------- Not sure if this has anything to do with Autotest or not. My suspicion is that it's buggy (rspec, not autotest) code. Let me know if I can do anything to help. ---------------------------------------------------------------------- >Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-09-24 02:13 Message: Thanks David ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-09-24 01:57 Message: Fixed in r2653 ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-09-15 20:57 Message: Oops: Forgot to attach my info: Ruby v. 186 Mac OS X.4.10 (Intel) rspec's trunk autotest, latest gem ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13969&group_id=797 From noreply at rubyforge.org Sun Sep 23 22:14:30 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 23 Sep 2007 22:14:30 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-13969 ] Spec Failures on Trunk w/ Autotest Message-ID: <20070924021430.D7E465240B98@rubyforge.org> Bugs item #13969, was opened at 2007-09-15 20:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13969&group_id=797 Category: Autotest Group: None Status: Closed Resolution: Accepted Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) Assigned to: Nobody (None) Summary: Spec Failures on Trunk w/ Autotest Initial Comment: Spec Failures are occurring when using autotest, but not when using the rake task: (This is occuring in trunk/rspec, at revision 2564): ------------------------------------------------------------------------- escher: autotest loading autotest/rspec /sw/bin/ruby1.8 -S bin/spec spec/spec/dsl/composite_proc_builder_spec.rb spec/spec/translator_spec.rb spec/spec/runner/option_parser_spec.rb spec/spec/dsl/predicate_matcher_spec.rb spec/spec/runner/heckler_spec.rb spec/spec/mocks/partial_mock_using_mocks_directly_spec.rb spec/spec/matchers/matcher_methods_spec.rb spec/spec/story/rspec_adapter.rb spec/spec/mocks/record_messages_spec.rb spec/spec/runner/formatter/failing_behaviours_formatter_spec.rb spec/spec/runner/command_line_spec.rb spec/spec/dsl/configuration_spec.rb spec/spec/runner/extensions/bug_report_10577_spec.rb spec/spec/matchers/operator_matcher_spec.rb spec/spec/matchers/be_spec.rb spec/spec/matchers/be_close_spec.rb spec/spec/runner/test_unit_and_rspec_spec.rb spec/spec/runner/formatter/progress_bar_formatter_spec.rb spec/spec/mocks/multiple_return_value_spec.rb spec/spec/runner/formatter/snippet_extractor_spec.rb spec/spec/package/bin_spec_spec.rb spec/spec/runner/reporter_spec.rb spec/spec/runner_spec.rb spec/spec/mocks/stub_spec.rb spec/spec/matchers/description_generation_spec.rb spec/spec/runner/formatter/html_formatter_spec.rb spec/spec/expectations/fail_with_spec.rb spec/spec/matchers/equal_spec.rb spec/spec/mocks/bug_report_7805_spec.rb spec/spec/runner/spec_parser_spec.rb spec/spec/runner/behaviour_runner_spec.rb spec/autotest/discover_spec.rb spec/spec/story/simple_step_spec.rb spec/spec/runner/quiet_backtrace_tweaker_spec.rb spec/spec/story/runner/scenario_runner_spec.rb spec/spec/runner/formatter/progress_bar_formatter_failure_dump_spec.rb spec/spec/runner/heckle_runner_spec.rb spec/spec/mocks/failing_mock_argument_constraints_spec.rb spec/spec/matchers/satisfy_spec.rb spec/spec/dsl/example_instance_spec.rb spec/spec/story/world_spec.rb spec/spec/story/story_spec.rb spec/spec/mocks/at_most_spec.rb spec/spec/mocks/bug_report_11545_spec.rb spec/spec/mocks/mock_ordering_spec.rb spec/spec/dsl/example_matcher_spec.rb spec/spec/story/given_scenario_spec.rb spec/spec/dsl/example_factory_spec.rb spec/spec/runner/formatter/specdoc_formatter_dry_run_spec.rb spec/spec/mocks/bug_report_10260_spec.rb spec/spec/mocks/precise_counts_spec.rb spec/spec/mocks/at_least_spec.rb spec/spec/story/runner_spec.rb spec/spec/runner/testrunnermediator_spec.rb spec/spec/mocks/bug_report_8302_spec.rb spec/spec/dsl/shared_behaviour_spec.rb spec/spec/mocks/passing_mock_argument_constraints_spec.rb spec/spec/runner/formatter/rdoc_formatter_dry_run_spec.rb spec/spec/story/runner/scenario_collector_spec.rb spec/spec/mocks/argument_expectation_spec.rb spec/spec/runner/options_spec.rb spec/spec/matchers/mock_constraint_matchers_spec.rb spec/spec/mocks/any_number_of_times_spec.rb spec/spec/matchers/has_spec.rb spec/spec/runner/object_ext_spec.rb spec/spec/mocks/options_hash_spec.rb spec/spec/dsl/example_definition_class_spec.rb spec/spec/matchers/respond_to_spec.rb spec/spec/mocks/mock_spec.rb spec/spec/mocks/bug_report_7611_spec.rb spec/spec/mocks/once_counts_spec.rb spec/spec/story/runner/story_runner_spec.rb spec/spec/runner/formatter/progress_bar_formatter_dry_run_spec.rb spec/spec/runner/formatter/specdoc_formatter_spec.rb spec/spec/matchers/handler_spec.rb spec/spec/story/step_mother_spec.rb spec/spec/runner/noisy_backtrace_tweaker_spec.rb spec/spec/matchers/eql_spec.rb spec/spec/matchers/include_spec.rb spec/autotest_helper.rb spec/spec/dsl/example_should_raise_spec.rb spec/rspec_suite.rb spec/spec/dsl/behaviour_description_spec.rb spec/spec/runner/formatter/rdoc_formatter_spec.rb spec/spec/spec_classes.rb spec/autotest/rspec_spec.rb spec/spec/story/reporter/plain_text_reporter_spec.rb spec/spec/story/story_helper.rb spec/spec/mocks/bug_report_8165_spec.rb spec/spec/story/documenter/plain_text_documenter_spec.rb spec/spec/matchers/change_spec.rb spec/spec/runner/execution_context_spec.rb spec/spec/mocks/twice_counts_spec.rb spec/spec/mocks/null_object_mock_spec.rb spec/spec/dsl/example_class_definition_spec.rb spec/spec/matchers/simple_matcher_spec.rb spec/spec/matchers/have_spec.rb spec/spec/matchers/raise_error_spec.rb spec/spec/mocks/mock_space_spec.rb spec/spec/runner/drb_command_line_spec.rb spec/spec/story/builders.rb spec/spec/dsl/example_suite_spec.rb spec/spec/runner/extensions/kernel_spec.rb spec/spec/dsl/example_spec.rb spec/spec/story/extensions_spec.rb spec/spec/dsl/example_definition_spec.rb spec/spec/expectations/differs/default_spec.rb spec/spec/runner/formatter/failing_examples_formatter_spec.rb spec/spec/story/scenario_spec.rb spec/spec/dsl/supports_pending_spec.rb spec/spec/matchers/throw_symbol_spec.rb spec/spec/matchers/match_spec.rb spec/spec/matchers/exist_spec.rb spec/spec/expectations/extensions/object_spec.rb spec/spec/mocks/partial_mock_spec.rb ..........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................P.....................................................................................................................................................................................................................................................................................................................................................P.......PP..................................F..F..........P.............. 1) 'should match(expected) should fail when target (String) matches expected (Regexp)' FAILED expected Spec::Expectations::ExpectationNotMetError, got #> ./spec/spec/matchers/match_spec.rb:9: 2) 'should_not match(expected) should fail when target (String) matches expected (Regexp)' FAILED expected Spec::Expectations::ExpectationNotMetError, got #> ./spec/spec/matchers/match_spec.rb:27: Finished in 5.699199 seconds 1049 examples, 2 failures, 5 pending Pending: a Mock expectation should clear expectations after verify (this fails if you run the file normally, but passes if you comment out the example at 116 or run the file in reverse) Example.suite should return an ExampleSuite with Examples (Not Yet Implemented) Example.class_eval should understand module scoping (Example.new needs to create a class that is evaled) Example.class_eval should allow class variables to be defined (class_eval cannot be used. Only the class definition can be used. This may not be possible.) Object#should should raise error if it receives nil (refactor the should method to handle this) ^CInterrupt a second time to quit ^Cescher: rake spec (in /Users/smt/src/ruby/rspec/trunk/rspec) ...............................................................................................................P.......PP..........................................................................P................................................................................................................................................................................................................................................................................................................................................................................................P............................................................................................................................................................................................................................................................................................................................................................................................................................................... Finished in 9.799042 seconds 1012 examples, 0 failures, 5 pending Pending: Example.suite should return an ExampleSuite with Examples (Not Yet Implemented) Example.class_eval should understand module scoping (Example.new needs to create a class that is evaled) Example.class_eval should allow class variables to be defined (class_eval cannot be used. Only the class definition can be used. This may not be possible.) Object#should should raise error if it receives nil (refactor the should method to handle this) a Mock expectation should clear expectations after verify (this fails if you run the file normally, but passes if you comment out the example at 116 or run the file in reverse) -------------------------------------------------------------------------------- Not sure if this has anything to do with Autotest or not. My suspicion is that it's buggy (rspec, not autotest) code. Let me know if I can do anything to help. ---------------------------------------------------------------------- >Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-09-24 02:14 Message: Thanks David ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-09-24 02:13 Message: Thanks David ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-09-24 01:57 Message: Fixed in r2653 ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-09-15 20:57 Message: Oops: Forgot to attach my info: Ruby v. 186 Mac OS X.4.10 (Intel) rspec's trunk autotest, latest gem ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13969&group_id=797 From noreply at rubyforge.org Sun Sep 23 23:14:50 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 23 Sep 2007 23:14:50 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-14166 ] Cannot build trunk Message-ID: <20070924031450.82BEA5240BED@rubyforge.org> Bugs item #14166, was opened at 2007-09-23 07:27 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=14166&group_id=797 Category: None Group: None Status: Closed Resolution: Accepted Priority: 3 Submitted By: Doug Wright (douglasdoright) Assigned to: David Chelimsky (dchelimsky) Summary: Cannot build trunk Initial Comment: I originally posted this on the rspec users list and David Chelimsky asked that I submit a bug. I really want to experiment with the new "Story Runner" functionality in rspec and I'm having trouble using the trunk. I've tried in both windows and linux environments and have different problems on each. On linux, I execute svn co svn://rubyforge.org/var/svn/rspec/trunk to check out the trunk. This completes successfully, so I try to build the gem. The readme on building says: "check out source from svn://rubyforge.org/var/svn/rspec/trunk. Then do the following: rake gem gem install pkg/rspec-0.x.x.gem (you may have to sudo)" This doesn't work in trunk, so I cd into trunk/rspec and execute rake gem. This fails with: dwright at hendrix:~/trunk/rspec$ rake gem (in /home/dwright/trunk/rspec) mkdir pkg rm -rf pkg/rspec_on_rails mkdir pkg rm -rf pkg/RSpec.tmbundle rake aborted! No such file or directory - ../spec_ui /home/dwright/trunk/rspec/Rakefile:227:in `chdir' (See full trace by running task with --trace) On windows (vista), I can't seem to successfully check out the project. When I execute: svn co svn://rubyforge.org/var/svn/rspec/trunk I get the following error part-way through the checkout: svn: In directory 'trunk\RSpec.tmbundle\Preferences' svn: Can't move 'trunk\RSpec.tmbundle\Preferences\.svn\tmp\Symbol List: Behaviour.tmPreferences.tmp.tmp' to 'trunk\RSpec.tmbundle\Preferences\.svn\tmp\Symbol List: Behaviour.tmPreferences.tmp': The parameter is incorrect. I can't proceed in this case because the checkout won't complete. ---------------------------------------------------------------------- >Comment By: Doug Wright (douglasdoright) Date: 2007-09-23 20:14 Message: Thank you very much! I'll make sure to submit separately next time. I'm looking forward to getting more competent with ruby, rails and rspec and one of my goals is to contribute to this project soon. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-09-23 13:13 Message: There are two separate issues here - building the gem and checking out on windows. Both are fixed as of r2646. In the future, please put separate issues in separate tickets. Thanks ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=14166&group_id=797 From brian.takita at gmail.com Mon Sep 24 00:43:26 2007 From: brian.takita at gmail.com (Brian Takita) Date: Sun, 23 Sep 2007 21:43:26 -0700 Subject: [rspec-devel] BehaviourRunner and ExampleSuite In-Reply-To: <1d7ddd110709222141w63ae5d29xb90d53da9d04cc6a@mail.gmail.com> References: <8d961d900709220809k76e7cd99i3ee32e02ff7979f9@mail.gmail.com> <8d961d900709220826x393a8037h552dd3da1337756b@mail.gmail.com> <1d7ddd110709222141w63ae5d29xb90d53da9d04cc6a@mail.gmail.com> Message-ID: <1d7ddd110709232143i111f1faamf6f4dc4610a2b8fd@mail.gmail.com> On 9/22/07, Brian Takita wrote: > On 9/22/07, aslak hellesoy wrote: > > The CHANGELOG says "Behaviour subclasses Test::Unit::TestCase". > > However, when I look in the code, the only subclass of TestCase is > > Example. There doesn't seem to be a Behaviour class at all anymore, > > but there are plenty of variables in the code named 'behaviour' > > > > For a long while we have been referring to "it" blocks as "examples", > > and they correspond to test_* methods in xUnit speak. Further, we used > > to call the describe blocks "behaviours" and they correspond to Test > > classes in xUnit speak. > > > > But now it looks like an "example" is analogous to a Test class?!?! > Currently Example is the Example instance and Behaviour is the Example > class. There is also a SharedBehaviour, which is a Module. > > Both the Example Class and SharedBehaviour include ExampleApi. It > seems like ExampleApi should be renamed to Behaviour. > > I think ExampleCallbacks can be merged into ExampleApi. > > ExampleDefinition is used by both SharedBehaviour and the Example > class. Example is the actual instance. It is created from an > ExampleDefinition. > > ExampleFactory probably should be renamed back to BehaviourFactory. > What do you think? > > ExampleMatcher should be renamed back to BehaviourMatcher and > ExampleMatcher#example_description and should be removed as it doesn't > seem to be used anymore. > > ExampleRunProxy is used by ExampleSuite run the Example block. > > ExampleShouldRaiseHandler handles should_raise options. > > ExampleSuite runs the Examples for the Example class. I have resolved the issues with these "Example" objects, except the ExampleMatcher, which was being used after all. I refactored it, though. I also removed the BehaviourRunner. There is only one call chain now, which is through Test::Unit::AutoRunner. This resolves the prepare being called several times issue. $behaviour_runner is replaced by $rspec_options. The prepare, run, and finish methods got moved to Options. Options seems like the wrong name for that object now, since it does actions such as running the examples. I've had good success with this "central" object in several projects, as it has centralized the internal state of the library. Some names I've used in the past is Registry, Space, Manager (eww), and Context (with rspec, there is a domain name conflict). The ExampleSuite object is largely untouched, and still needs to be refactored. Rspec adds two callbacks to the TestRunnerMediator object. The callbacks call the Options#prepare and Options#finish methods. How does everything look? Are there other areas of confusion? Thanks, Brian > > > > There are 9 (!) example_* files and it's virtually impossible to tell > > where responsibilities are. Although I'm against extensive > > documentation in code explaining how the code works internally > > (because code should be self documenting) I think we're now at a point > > where we need to add comments or clean things up bigtime. > I think things should be cleaned up to be more understandable. > The previous versions of rspec were very difficult to understand too. > There were a number of things in the wrong places that have been > untangled, and there is still more work to do. > Since things are different, this is a great opportunity to see it from > the eyes of unfamiliarity and make it easier to grok. > > > > > I'm really confused. > > > > On 9/22/07, aslak hellesoy wrote: > > > Hi, > > > > > > I've noticed that BehaviourRunner#prepare is invoked via two different chains: > > > > > > bin/spec -> CommandLine#run -> BehaviourRunner#run -> BehaviourRunner#prepare > > > test/unit/testsuite.rb -> ExampleSute#run -> BehaviourRunner#prepare > > > > > > In one single run, #prepare gets called twice, and returns the second > > > time because of the @already_prepared check. > > > > > > This is all quite confusing to me, and the number of delegators in > > > ExampleSuite makes it even more confusing. Now that we're using > > > Test::Unit's runner it occurs to me that we should get rid of our own > > > "runner" stuff, but there still seems to be a lot of redundancy. The > > > code is plain hard to understand. > > > > > > You who've been involved in the Test::Unit refactoring - are you > > > planning to simplify things more and get rid of our own runner? > > > > > > Aslak > > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > From noreply at rubyforge.org Mon Sep 24 02:00:25 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 24 Sep 2007 02:00:25 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-14174 ] Seamless transition from Test::Unit Message-ID: <20070924060025.E31025240F05@rubyforge.org> Feature Requests item #14174, was opened at 2007-09-23 23:00 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=14174&group_id=797 Category: runner module Group: None Status: Open Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Seamless transition from Test::Unit Initial Comment: test_ methods with an arity of 0 defined in a describe block or Example object will be run as an Example, providing a seamless transition from Test::Unit This was checked in Rev 2564. Lets say somebody wants to try rspec. Now they can with minimal fuss. class FooTest < Test::Unit::TestCase def test_something assert true end end to: # This now creates an Example class FooSpec < Spec::DSL::Example def test_something assert true end end to: class FooSpec < Spec::DSL::Example it "should assert something" do true.should be_true end end to: describe Foo do it "should assert something" do true.should be_true end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=14174&group_id=797 From noreply at rubyforge.org Mon Sep 24 02:00:38 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 24 Sep 2007 02:00:38 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-14174 ] Seamless transition from Test::Unit Message-ID: <20070924060038.737A25240F21@rubyforge.org> Feature Requests item #14174, was opened at 2007-09-23 23:00 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=14174&group_id=797 Category: runner module Group: None >Status: Closed Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Seamless transition from Test::Unit Initial Comment: test_ methods with an arity of 0 defined in a describe block or Example object will be run as an Example, providing a seamless transition from Test::Unit This was checked in Rev 2564. Lets say somebody wants to try rspec. Now they can with minimal fuss. class FooTest < Test::Unit::TestCase def test_something assert true end end to: # This now creates an Example class FooSpec < Spec::DSL::Example def test_something assert true end end to: class FooSpec < Spec::DSL::Example it "should assert something" do true.should be_true end end to: describe Foo do it "should assert something" do true.should be_true end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=14174&group_id=797 From aslak.hellesoy at gmail.com Mon Sep 24 04:38:18 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Mon, 24 Sep 2007 10:38:18 +0200 Subject: [rspec-devel] BehaviourRunner and ExampleSuite In-Reply-To: <1d7ddd110709232143i111f1faamf6f4dc4610a2b8fd@mail.gmail.com> References: <8d961d900709220809k76e7cd99i3ee32e02ff7979f9@mail.gmail.com> <8d961d900709220826x393a8037h552dd3da1337756b@mail.gmail.com> <1d7ddd110709222141w63ae5d29xb90d53da9d04cc6a@mail.gmail.com> <1d7ddd110709232143i111f1faamf6f4dc4610a2b8fd@mail.gmail.com> Message-ID: <8d961d900709240138r41f329fpa90dcf0ecfdd1d12@mail.gmail.com> On 9/24/07, Brian Takita wrote: > On 9/22/07, Brian Takita wrote: > > On 9/22/07, aslak hellesoy wrote: > > > The CHANGELOG says "Behaviour subclasses Test::Unit::TestCase". > > > However, when I look in the code, the only subclass of TestCase is > > > Example. There doesn't seem to be a Behaviour class at all anymore, > > > but there are plenty of variables in the code named 'behaviour' > > > > > > For a long while we have been referring to "it" blocks as "examples", > > > and they correspond to test_* methods in xUnit speak. Further, we used > > > to call the describe blocks "behaviours" and they correspond to Test > > > classes in xUnit speak. > > > > > > But now it looks like an "example" is analogous to a Test class?!?! > > Currently Example is the Example instance and Behaviour is the Example > > class. There is also a SharedBehaviour, which is a Module. > > > > Both the Example Class and SharedBehaviour include ExampleApi. It > > seems like ExampleApi should be renamed to Behaviour. > > > > I think ExampleCallbacks can be merged into ExampleApi. > > > > ExampleDefinition is used by both SharedBehaviour and the Example > > class. Example is the actual instance. It is created from an > > ExampleDefinition. > > > > ExampleFactory probably should be renamed back to BehaviourFactory. > > What do you think? > > > > ExampleMatcher should be renamed back to BehaviourMatcher and > > ExampleMatcher#example_description and should be removed as it doesn't > > seem to be used anymore. > > > > ExampleRunProxy is used by ExampleSuite run the Example block. > > > > ExampleShouldRaiseHandler handles should_raise options. > > > > ExampleSuite runs the Examples for the Example class. > I have resolved the issues with these "Example" objects, except the > ExampleMatcher, which was being used after all. I refactored it, > though. > > I also removed the BehaviourRunner. There is only one call chain now, > which is through Test::Unit::AutoRunner. > This resolves the prepare being called several times issue. > > $behaviour_runner is replaced by $rspec_options. > The prepare, run, and finish methods got moved to Options. Options > seems like the wrong name for that object now, since it does actions > such as running the examples. > I've had good success with this "central" object in several projects, > as it has centralized the internal state of the library. > > Some names I've used in the past is Registry, Space, Manager (eww), > and Context (with rspec, there is a domain name conflict). > > The ExampleSuite object is largely untouched, and still needs to be refactored. > Rspec adds two callbacks to the TestRunnerMediator object. The > callbacks call the Options#prepare and Options#finish methods. > > How does everything look? Are there other areas of confusion? > The --runner option is gone. I'm on a project that relies on this feature. We use RSpec to run Watir, and on a single machine it takes 2 hours. With a custom runner (in the Spec::Distributed project on rspec-ext.rubyforge.org) we're able to run in parallel in 20 minutes. Needless, to say - we're absolutely dependent on the --runner command line switch that you just removed. Please put it back. I realise this will mean that the Test::Unit runner and Behaviour runner duplication problem is not solved, but we cannot just remove features nilly willy. Aslak > Thanks, > Brian > > > > > > There are 9 (!) example_* files and it's virtually impossible to tell > > > where responsibilities are. Although I'm against extensive > > > documentation in code explaining how the code works internally > > > (because code should be self documenting) I think we're now at a point > > > where we need to add comments or clean things up bigtime. > > I think things should be cleaned up to be more understandable. > > The previous versions of rspec were very difficult to understand too. > > There were a number of things in the wrong places that have been > > untangled, and there is still more work to do. > > Since things are different, this is a great opportunity to see it from > > the eyes of unfamiliarity and make it easier to grok. > > > > > > > > I'm really confused. > > > > > > On 9/22/07, aslak hellesoy wrote: > > > > Hi, > > > > > > > > I've noticed that BehaviourRunner#prepare is invoked via two different chains: > > > > > > > > bin/spec -> CommandLine#run -> BehaviourRunner#run -> BehaviourRunner#prepare > > > > test/unit/testsuite.rb -> ExampleSute#run -> BehaviourRunner#prepare > > > > > > > > In one single run, #prepare gets called twice, and returns the second > > > > time because of the @already_prepared check. > > > > > > > > This is all quite confusing to me, and the number of delegators in > > > > ExampleSuite makes it even more confusing. Now that we're using > > > > Test::Unit's runner it occurs to me that we should get rid of our own > > > > "runner" stuff, but there still seems to be a lot of redundancy. The > > > > code is plain hard to understand. > > > > > > > > You who've been involved in the Test::Unit refactoring - are you > > > > planning to simplify things more and get rid of our own runner? > > > > > > > > Aslak > > > > > > > _______________________________________________ > > > rspec-devel mailing list > > > rspec-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From aslak.hellesoy at gmail.com Mon Sep 24 04:44:41 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Mon, 24 Sep 2007 10:44:41 +0200 Subject: [rspec-devel] BehaviourRunner and ExampleSuite In-Reply-To: <8d961d900709240138r41f329fpa90dcf0ecfdd1d12@mail.gmail.com> References: <8d961d900709220809k76e7cd99i3ee32e02ff7979f9@mail.gmail.com> <8d961d900709220826x393a8037h552dd3da1337756b@mail.gmail.com> <1d7ddd110709222141w63ae5d29xb90d53da9d04cc6a@mail.gmail.com> <1d7ddd110709232143i111f1faamf6f4dc4610a2b8fd@mail.gmail.com> <8d961d900709240138r41f329fpa90dcf0ecfdd1d12@mail.gmail.com> Message-ID: <8d961d900709240144j657a7dj2c023b3905892b6f@mail.gmail.com> The --reverse option used to run the behaviours AND their examples in opposite order. Now it's only the examples that get run in opposite order. This is another feature we're relying on in order to discover accidentally dependant specs. It would be great to have this back too. Aslak On 9/24/07, aslak hellesoy wrote: > On 9/24/07, Brian Takita wrote: > > On 9/22/07, Brian Takita wrote: > > > On 9/22/07, aslak hellesoy wrote: > > > > The CHANGELOG says "Behaviour subclasses Test::Unit::TestCase". > > > > However, when I look in the code, the only subclass of TestCase is > > > > Example. There doesn't seem to be a Behaviour class at all anymore, > > > > but there are plenty of variables in the code named 'behaviour' > > > > > > > > For a long while we have been referring to "it" blocks as "examples", > > > > and they correspond to test_* methods in xUnit speak. Further, we used > > > > to call the describe blocks "behaviours" and they correspond to Test > > > > classes in xUnit speak. > > > > > > > > But now it looks like an "example" is analogous to a Test class?!?! > > > Currently Example is the Example instance and Behaviour is the Example > > > class. There is also a SharedBehaviour, which is a Module. > > > > > > Both the Example Class and SharedBehaviour include ExampleApi. It > > > seems like ExampleApi should be renamed to Behaviour. > > > > > > I think ExampleCallbacks can be merged into ExampleApi. > > > > > > ExampleDefinition is used by both SharedBehaviour and the Example > > > class. Example is the actual instance. It is created from an > > > ExampleDefinition. > > > > > > ExampleFactory probably should be renamed back to BehaviourFactory. > > > What do you think? > > > > > > ExampleMatcher should be renamed back to BehaviourMatcher and > > > ExampleMatcher#example_description and should be removed as it doesn't > > > seem to be used anymore. > > > > > > ExampleRunProxy is used by ExampleSuite run the Example block. > > > > > > ExampleShouldRaiseHandler handles should_raise options. > > > > > > ExampleSuite runs the Examples for the Example class. > > I have resolved the issues with these "Example" objects, except the > > ExampleMatcher, which was being used after all. I refactored it, > > though. > > > > I also removed the BehaviourRunner. There is only one call chain now, > > which is through Test::Unit::AutoRunner. > > This resolves the prepare being called several times issue. > > > > $behaviour_runner is replaced by $rspec_options. > > The prepare, run, and finish methods got moved to Options. Options > > seems like the wrong name for that object now, since it does actions > > such as running the examples. > > I've had good success with this "central" object in several projects, > > as it has centralized the internal state of the library. > > > > Some names I've used in the past is Registry, Space, Manager (eww), > > and Context (with rspec, there is a domain name conflict). > > > > The ExampleSuite object is largely untouched, and still needs to be refactored. > > Rspec adds two callbacks to the TestRunnerMediator object. The > > callbacks call the Options#prepare and Options#finish methods. > > > > How does everything look? Are there other areas of confusion? > > > > The --runner option is gone. I'm on a project that relies on this > feature. We use RSpec to run Watir, and on a single machine it takes 2 > hours. With a custom runner (in the Spec::Distributed project on > rspec-ext.rubyforge.org) we're able to run in parallel in 20 minutes. > > Needless, to say - we're absolutely dependent on the --runner command > line switch that you just removed. Please put it back. > > I realise this will mean that the Test::Unit runner and Behaviour > runner duplication problem is not solved, but we cannot just remove > features nilly willy. > > Aslak > > > Thanks, > > Brian > > > > > > > > There are 9 (!) example_* files and it's virtually impossible to tell > > > > where responsibilities are. Although I'm against extensive > > > > documentation in code explaining how the code works internally > > > > (because code should be self documenting) I think we're now at a point > > > > where we need to add comments or clean things up bigtime. > > > I think things should be cleaned up to be more understandable. > > > The previous versions of rspec were very difficult to understand too. > > > There were a number of things in the wrong places that have been > > > untangled, and there is still more work to do. > > > Since things are different, this is a great opportunity to see it from > > > the eyes of unfamiliarity and make it easier to grok. > > > > > > > > > > > I'm really confused. > > > > > > > > On 9/22/07, aslak hellesoy wrote: > > > > > Hi, > > > > > > > > > > I've noticed that BehaviourRunner#prepare is invoked via two different chains: > > > > > > > > > > bin/spec -> CommandLine#run -> BehaviourRunner#run -> BehaviourRunner#prepare > > > > > test/unit/testsuite.rb -> ExampleSute#run -> BehaviourRunner#prepare > > > > > > > > > > In one single run, #prepare gets called twice, and returns the second > > > > > time because of the @already_prepared check. > > > > > > > > > > This is all quite confusing to me, and the number of delegators in > > > > > ExampleSuite makes it even more confusing. Now that we're using > > > > > Test::Unit's runner it occurs to me that we should get rid of our own > > > > > "runner" stuff, but there still seems to be a lot of redundancy. The > > > > > code is plain hard to understand. > > > > > > > > > > You who've been involved in the Test::Unit refactoring - are you > > > > > planning to simplify things more and get rid of our own runner? > > > > > > > > > > Aslak > > > > > > > > > _______________________________________________ > > > > rspec-devel mailing list > > > > rspec-devel at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > From noreply at rubyforge.org Mon Sep 24 09:44:14 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 24 Sep 2007 09:44:14 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-14183 ] Tiny improvement on mock_spec.rb Message-ID: <20070924134415.105DE5240BAA@rubyforge.org> Patches item #14183, was opened at 2007-09-24 15:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14183&group_id=797 Category: mock module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Antti Tarvainen (tarvaina) Assigned to: Nobody (None) Summary: Tiny improvement on mock_spec.rb Initial Comment: Just a tiny patch to fix an example in mock_spec.rb. Now it doesn't break when you add more examples or rename the file. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14183&group_id=797 From noreply at rubyforge.org Mon Sep 24 09:45:16 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 24 Sep 2007 09:45:16 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-14183 ] Tiny improvement on mock_spec.rb Message-ID: <20070924134517.6A2295240B56@rubyforge.org> Patches item #14183, was opened at 2007-09-24 15:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14183&group_id=797 Category: mock module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Antti Tarvainen (tarvaina) Assigned to: Nobody (None) Summary: Tiny improvement on mock_spec.rb Initial Comment: Just a tiny patch to fix an example in mock_spec.rb. Now it doesn't break when you add more examples or rename the file. ---------------------------------------------------------------------- >Comment By: Antti Tarvainen (tarvaina) Date: 2007-09-24 15:45 Message: (Forgot to check the upload box.) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14183&group_id=797 From noreply at rubyforge.org Mon Sep 24 11:32:36 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 24 Sep 2007 11:32:36 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-14186 ] Remove dead code from message_expecation.rb Message-ID: <20070924153236.311F45240B02@rubyforge.org> Patches item #14186, was opened at 2007-09-24 17:32 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14186&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Antti Tarvainen (tarvaina) Assigned to: Nobody (None) Summary: Remove dead code from message_expecation.rb Initial Comment: This patch removes dead code from message_expectation.rb. The variable @exception_instance_to_raise was not used anywhere. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14186&group_id=797 From noreply at rubyforge.org Mon Sep 24 12:01:40 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 24 Sep 2007 12:01:40 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-14109 ] RailsStory dies badly when no fixtures present Message-ID: <20070924160140.491A95240BCA@rubyforge.org> Patches item #14109, was opened at 2007-09-20 17:04 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14109&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: James Hughes (jpath) Assigned to: Nobody (None) Summary: RailsStory dies badly when no fixtures present Initial Comment: A story like the following: Story 'Something happens', %{ As a user I want to do something So that something will happen. }, :type => RailsStory do Scenario 'User doing something for first time' do Given 'a user' do @user = User.new end When 'the user makes a request' do post '/some_action', :id => 1 end Then 'something should happen' do end end end will die attempting to post when there are no fixtures present (at least, I think that's what's happening.) It dies at the following line in rails/actionpack/lib/action_controller/integration.rb: self.class.fixture_table_names.each do |table_name| 'self.class' at this point is RailsStory. The attached patch just initializes fixture_table_names to an empty array. ---------------------------------------------------------------------- >Comment By: James Hughes (jpath) Date: 2007-09-24 16:01 Message: Ok, I've played with this a bit more, and the error seems to just be with edge rails. Latest rails gem fails too, but with a different error. My original patch has no effect on this error, so, probably just a 'works for me' solution. First, steps to reproduce: Create a brand new rails app and freeze to edge Do 'script/generate rspec_model user' Put the story as it appears here in the stories folder (See attached file) Run 'ruby stories/test_story.rb' This should produce the following stack trace: FAILURES: 1) Something happens (User doing something for first time) FAILED NoMethodError: You have a nil object when you didn't expect it! You might have expected an instance of Array. The error occurred while evaluating nil.each /home/jhughes/dev/rspec_story_regression/vendor/rails/actionpack/lib/action_controller/integration.rb:522:in `open_session' /home/jhughes/dev/rspec_story_regression/vendor/rails/actionpack/lib/action_controller/integration.rb:493:in `reset!' /home/jhughes/dev/rspec_story_regression/vendor/rails/actionpack/lib/action_controller/integration.rb:498:in `post' stories/test_story.rb:17:in `the user makes a request' /home/jhughes/dev/rspec_story_regression/vendor/plugins/rspec/lib/spec/story/simple_step.rb:13:in `__send__' /home/jhughes/dev/rspec_story_regression/vendor/plugins/rspec/lib/spec/story/simple_step.rb:13:in `perform' /home/jhughes/dev/rspec_story_regression/vendor/plugins/rspec/lib/spec/story/world.rb:58:in `store_and_call' /home/jhughes/dev/rspec_story_regression/vendor/plugins/rspec/lib/spec/story/world.rb:73:in `When' stories/test_story.rb:16 /home/jhughes/dev/rspec_story_regression/vendor/plugins/rspec/lib/spec/story/runner/scenario_runner.rb:14:in `instance_eval' /home/jhughes/dev/rspec_story_regression/vendor/plugins/rspec/lib/spec/story/runner/scenario_runner.rb:14:in `run' /home/jhughes/dev/rspec_story_regression/vendor/plugins/rspec/lib/spec/story/runner/story_runner.rb:48:in `run_stories' /home/jhughes/dev/rspec_story_regression/vendor/plugins/rspec/lib/spec/story/runner/story_runner.rb:43:in `each' /home/jhughes/dev/rspec_story_regression/vendor/plugins/rspec/lib/spec/story/runner/story_runner.rb:43:in `run_stories' /home/jhughes/dev/rspec_story_regression/vendor/plugins/rspec/lib/spec/story/runner/story_runner.rb:39:in `each' /home/jhughes/dev/rspec_story_regression/vendor/plugins/rspec/lib/spec/story/runner/story_runner.rb:39:in `run_stories' /home/jhughes/dev/rspec_story_regression/vendor/plugins/rspec/lib/spec/story/runner.rb:38:in `register_exit_hook' stories/test_story.rb:6 With the latest rails gem instead of edge, I get (note, again, this happens whether my patch is applied or not: /usr/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/initializer.rb:328:in `send': undefined method `session=' for ActionController::Base:Class (NoMethodError) from /usr/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/initializer.rb:328:in `initialize_framework_settings' from /usr/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/initializer.rb:327:in `each' from /usr/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/initializer.rb:327:in `initialize_framework_settings' from /usr/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/initializer.rb:324:in `each' from /usr/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/initializer.rb:324:in `initialize_framework_settings' from /usr/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/initializer.rb:96:in `process' from /usr/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/initializer.rb:43:in `send' from /usr/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/initializer.rb:43:in `run' from /home/jhughes/dev/rspec_story_regression/config/environment.rb:13 from stories/test_story.rb:2:in `require' from stories/test_story.rb:2 ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-09-23 03:56 Message: Please post a real example with a real stack trace. I haven't seen this problem and would like to understand it better before adding anything like this. Cheers, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14109&group_id=797 From noreply at rubyforge.org Tue Sep 25 01:45:50 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 25 Sep 2007 01:45:50 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-14208 ] Fix to Mock#method_missing raising NameErrors instead of MockExpectationErrors Message-ID: <20070925054551.1E6CE5240F5E@rubyforge.org> Patches item #14208, was opened at 2007-09-25 07:45 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14208&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Antti Tarvainen (tarvaina) Assigned to: Nobody (None) Summary: Fix to Mock#method_missing raising NameErrors instead of MockExpectationErrors Initial Comment: This patch fixes the nasty heisenbug in mock.rb. Symptom: -------- Every now and then mocks would throw NameErrors instead of MockExpectationErrors when they received unexpected method calls -- but sure enough, not when running the program in a debugger. Cause: ------ Ruby's Object#method_missing throws either NameErrors or NoMethodErrors. On a fresh ruby program Object#method_missing raises: * NoMethodError when called directly (object.method_missing :foo) * NameError when called indirectly (object.foo) Once Object#method_missing has been called at least once (on any object) it starts raising: * NameError when called directly * NameError when called indirectly It is also possible for method_missing to go back to the original state, but I don't know when this happens. Why Object#method_missing behaves this way, I have no idea. The version of Ruby I use is ruby 1.8.6 (2007-03-13 patchlevel 0) [i686-darwin8.9.1]. Mock#method_missing relied on the assumption that calling Object#method_missing directly causes a NoMethodError to be raised. Fix: ---- Mock#method_missing now converts all kinds of NameErrors (instead of just NoMethodErrors) into MockExpectationErrors. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14208&group_id=797 From noreply at rubyforge.org Tue Sep 25 01:47:46 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 25 Sep 2007 01:47:46 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-14208 ] Fix to Mock#method_missing raising NameErrors instead of MockExpectationErrors Message-ID: <20070925054746.76C805240F5E@rubyforge.org> Patches item #14208, was opened at 2007-09-25 07:45 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14208&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Antti Tarvainen (tarvaina) Assigned to: Nobody (None) Summary: Fix to Mock#method_missing raising NameErrors instead of MockExpectationErrors Initial Comment: This patch fixes the nasty heisenbug in mock.rb. Symptom: -------- Every now and then mocks would throw NameErrors instead of MockExpectationErrors when they received unexpected method calls -- but sure enough, not when running the program in a debugger. Cause: ------ Ruby's Object#method_missing throws either NameErrors or NoMethodErrors. On a fresh ruby program Object#method_missing raises: * NoMethodError when called directly (object.method_missing :foo) * NameError when called indirectly (object.foo) Once Object#method_missing has been called at least once (on any object) it starts raising: * NameError when called directly * NameError when called indirectly It is also possible for method_missing to go back to the original state, but I don't know when this happens. Why Object#method_missing behaves this way, I have no idea. The version of Ruby I use is ruby 1.8.6 (2007-03-13 patchlevel 0) [i686-darwin8.9.1]. Mock#method_missing relied on the assumption that calling Object#method_missing directly causes a NoMethodError to be raised. Fix: ---- Mock#method_missing now converts all kinds of NameErrors (instead of just NoMethodErrors) into MockExpectationErrors. ---------------------------------------------------------------------- >Comment By: Antti Tarvainen (tarvaina) Date: 2007-09-25 07:47 Message: Here's a test/unit test case that illustrates the weird behavior of Object#method_missing. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14208&group_id=797 From noreply at rubyforge.org Tue Sep 25 08:34:12 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 25 Sep 2007 08:34:12 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-14174 ] Seamless transition from Test::Unit Message-ID: <20070925123412.D4C5D5240B9F@rubyforge.org> Feature Requests item #14174, was opened at 2007-09-24 02:00 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=14174&group_id=797 Category: runner module Group: None Status: Closed Priority: 3 Submitted By: Brian Takita (btakita) Assigned to: Nobody (None) Summary: Seamless transition from Test::Unit Initial Comment: test_ methods with an arity of 0 defined in a describe block or Example object will be run as an Example, providing a seamless transition from Test::Unit This was checked in Rev 2564. Lets say somebody wants to try rspec. Now they can with minimal fuss. class FooTest < Test::Unit::TestCase def test_something assert true end end to: # This now creates an Example class FooSpec < Spec::DSL::Example def test_something assert true end end to: class FooSpec < Spec::DSL::Example it "should assert something" do true.should be_true end end to: describe Foo do it "should assert something" do true.should be_true end end ---------------------------------------------------------------------- >Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-09-25 08:34 Message: I don't see the value in introducing a step that only changes the superclass. Wouldn't this be better? 1) class FooTest < Test::Unit::TestCase def test_something assert true end end 2a) class FooTest < Test::Unit::TestCase it "should assert something" do assert true end end 2b) describe Foo do def test_something assert true end end 3) describe Foo do it "should assert something" do assert true end end 4) describe Foo do it "should assert something" do true.should be_true end end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=14174&group_id=797 From matt-lists at reprocessed.org Wed Sep 26 05:40:30 2007 From: matt-lists at reprocessed.org (Matt Patterson) Date: Wed, 26 Sep 2007 10:40:30 +0100 Subject: [rspec-devel] The structure of the rspec tests Message-ID: <09076930-B739-45A6-B1D7-D713082368F0@reprocessed.org> Morning, I'm trying to get a handle on the way that RSpec's own tests are structured and run. I've figured out how to do rake pre_commit, but I'm trying to see how the pluggable mock framework stuff is tested, and there seem to be things in the rspec/examples and rspec/failing_examples directories, and not sure I understand exactly how and if these are (should?) be run. Could someone give me a whistlestop tour of the basic structure and setup? Thanks, Matt -- Matt Patterson | Design & Code | http://www.reprocessed.org/ From dchelimsky at gmail.com Wed Sep 26 09:00:04 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 26 Sep 2007 08:00:04 -0500 Subject: [rspec-devel] The structure of the rspec tests In-Reply-To: <09076930-B739-45A6-B1D7-D713082368F0@reprocessed.org> References: <09076930-B739-45A6-B1D7-D713082368F0@reprocessed.org> Message-ID: <57c63afe0709260600k4b1abd34i93e1cc59bd4ca1d2@mail.gmail.com> On 9/26/07, Matt Patterson wrote: > Morning, > > I'm trying to get a handle on the way that RSpec's own tests are > structured and run. > > I've figured out how to do rake pre_commit, but I'm trying to see how > the pluggable mock framework stuff is tested, There was a problem spec'ing the plugins due to the fact that both mocha and rspec modify Object, so I really just punted on those. They do not get tested when we run pre-commit. Now that you've caught me red-handed on that - the way it could work is to spawn a separate process. Patches welcome! > and there seem to be > things in the rspec/examples and rspec/failing_examples directories, > and not sure I understand exactly how and if these are (should?) be run. Some of those get run w/ the pre_commit in order to test the CommandLine, but we don't consider them as part of the suite. > Could someone give me a whistlestop tour of the basic structure and > setup? > > Thanks, > > Matt > > > -- > Matt Patterson | Design & Code > | http://www.reprocessed.org/ > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From noreply at rubyforge.org Wed Sep 26 13:07:58 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 26 Sep 2007 13:07:58 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-14254 ] Improved error handling for Object#should and Object#should_not Message-ID: <20070926170758.DF7F55240B65@rubyforge.org> Patches item #14254, was opened at 2007-09-26 19:07 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14254&group_id=797 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Antti Tarvainen (tarvaina) Assigned to: Nobody (None) Summary: Improved error handling for Object#should and Object#should_not Initial Comment: This patch improves the error handling of Object#should and Object#should_not methods. It does two things: 1. It causes an InvalidMatcherError to be raised when something else besides a matcher is given to a should expression as a parameter. Before the patch, the type of exception depended on context and was either NoMethodError or ExpectationNotMetError, depending on the context. 2. It catches cases where a nil parameter is given as a matcher. (There was a pending example in the specs for this one.) Note that cases where no matcher argument is given to a should expression are not caught and will continue to give no warnings. I made a pending example for this but I doubt there's a way to solve it. Summarising: # These all will now raise InvalidMatcherError object.should 5 object.should false object.should nil object.should eql?("foo") object.should_not 5 object.should_not false object.should_not nil object.should_not eql?("foo") # As before, these will pass without a warning object.should object.should_not ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14254&group_id=797 From noreply at rubyforge.org Wed Sep 26 13:11:10 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 26 Sep 2007 13:11:10 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-14255 ] Fixed examples in mock_spec.rb and shared_behaviour_spec.rb Message-ID: <20070926171110.CAFD45240B56@rubyforge.org> Patches item #14255, was opened at 2007-09-26 19:11 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14255&group_id=797 Category: mock module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Antti Tarvainen (tarvaina) Assigned to: Nobody (None) Summary: Fixed examples in mock_spec.rb and shared_behaviour_spec.rb Initial Comment: A recurring pattern in rspec internal examples is this: it "should fail with a meaningful error message" do begin @object.failing_operation rescue PanicExceptionError => e e.message.should == "Something went wrong!" end end The problem with this pattern is that it gives a false positive when @object.failing_operation doesn't raise a PanicExceptionError. This patch fixes these examples by using the raise_error matcher. The above example thus becomes: it "should fail with a meaningful error message" do lambda { @object.failing_operation }.should raise_error(PanicExceptionError, "Something went wrong!") end These changes revealed one false positive in mock_spec.rb. I marked the example pending and added another example that demonstrates the current behavior. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14255&group_id=797 From noreply at rubyforge.org Wed Sep 26 13:11:54 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 26 Sep 2007 13:11:54 -0400 (EDT) Subject: [rspec-devel] [ rspec-Patches-14255 ] Fixed examples in mock_spec.rb and shared_behaviour_spec.rb Message-ID: <20070926171154.227685240B62@rubyforge.org> Patches item #14255, was opened at 2007-09-26 19:11 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14255&group_id=797 Category: mock module Group: None Status: Open Resolution: None Priority: 3 Submitted By: Antti Tarvainen (tarvaina) Assigned to: Nobody (None) Summary: Fixed examples in mock_spec.rb and shared_behaviour_spec.rb Initial Comment: A recurring pattern in rspec internal examples is this: it "should fail with a meaningful error message" do begin @object.failing_operation rescue PanicExceptionError => e e.message.should == "Something went wrong!" end end The problem with this pattern is that it gives a false positive when @object.failing_operation doesn't raise a PanicExceptionError. This patch fixes these examples by using the raise_error matcher. The above example thus becomes: it "should fail with a meaningful error message" do lambda { @object.failing_operation }.should raise_error(PanicExceptionError, "Something went wrong!") end These changes revealed one false positive in mock_spec.rb. I marked the example pending and added another example that demonstrates the current behavior. ---------------------------------------------------------------------- >Comment By: Antti Tarvainen (tarvaina) Date: 2007-09-26 19:11 Message: Here's the actual patch file. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14255&group_id=797 From matt-lists at reprocessed.org Wed Sep 26 13:17:49 2007 From: matt-lists at reprocessed.org (Matt Patterson) Date: Wed, 26 Sep 2007 18:17:49 +0100 Subject: [rspec-devel] template.expect_render Message-ID: I've been chasing down a problem with template.expect_render where, if you're using mocha, the expectations don't get verified. I have a spec like this: > describe "/complex/view" do > it "should create entries with titles" do > template.expect_render(:partial => 'nonsense') > > render "/complex/view" > end > end Which passes when it should fail. This spec, however, fails as it ought: > describe "/complex/view" do > it "should create entries with titles" do > template.expect_render(:partial => 'nonsense') > > render "/complex/view" > > template.verify_rendered > end > end I'm pleased to note that it's been fixed in trunk. The big change I could see was a shift from calling after and remove_after on Spec::DSL::Behaviour to calling them on Spec::DSL::Example. I'm intrigued by what changed here, because the problem clearly was that template.verify_rendered wasn't being called after the spec ran... Can anyone shed some light on this? It would help my knowledge of the internals no end... Thanks, Matt -- Matt Patterson | Design & Code | http://www.reprocessed.org/ From padraic.brady at yahoo.com Wed Sep 26 16:32:48 2007 From: padraic.brady at yahoo.com (=?iso-8859-1?Q?P=E1draic_Brady?=) Date: Wed, 26 Sep 2007 13:32:48 -0700 (PDT) Subject: [rspec-devel] RSpec for PHP Message-ID: <854376.77372.qm@web55315.mail.re4.yahoo.com> Hi all, I've been using RSpec for many months now while learning Ruby, and have enjoyed following the BDD evolution. After recently returning to PHP (where most of my work lies) I found the lack of RSpec to be a bitter pill. So in collaboration with another PHP developer we intend to start work on a PHPSpec framework and convert a few natives here in the PHP community. We're hoping Terry Chay doesn't notice until it's too late ;). Any comments, words of support, or suggestions are most appreciated. Passing it by the list as an FYI. Best regards, Paddy P?draic Brady http://blog.astrumfutura.com http://www.patternsforphp.com OpenID Europe Foundation Member-Subscriber ____________________________________________________________________________________ Tonight's top picks. What will you watch tonight? Preview the hottest shows on Yahoo! TV. http://tv.yahoo.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070926/f0d940f2/attachment-0001.html From aslak.hellesoy at gmail.com Wed Sep 26 17:08:47 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Wed, 26 Sep 2007 23:08:47 +0200 Subject: [rspec-devel] RSpec for PHP In-Reply-To: <854376.77372.qm@web55315.mail.re4.yahoo.com> References: <854376.77372.qm@web55315.mail.re4.yahoo.com> Message-ID: <8d961d900709261408m3bbf1cfj27b87ad3c9901ca2@mail.gmail.com> On 9/26/07, P?draic Brady wrote: > > Hi all, > > I've been using RSpec for many months now while learning Ruby, and have > enjoyed following the BDD evolution. After recently returning to PHP (where > most of my work lies) I found the lack of RSpec to be a bitter pill. > > So in collaboration with another PHP developer we intend to start work on a > PHPSpec framework and convert a few natives here in the PHP community. We're > hoping Terry Chay doesn't notice until it's too late ;). > > Any comments, words of support, or suggestions are most appreciated. Passing > it by the list as an FYI. > All I have to say is AWESOME, even if I don't use PHP. Glad to have contributed to a valuable concept :-) Aslak > Best regards, > Paddy > P?draic Brady > > http://blog.astrumfutura.com > http://www.patternsforphp.com > OpenID Europe Foundation Member-Subscriber > > > ________________________________ > Building a website is a piece of cake. > Yahoo! Small Business gives you all the tools to get online. > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From aslak.hellesoy at gmail.com Thu Sep 27 18:29:14 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Fri, 28 Sep 2007 00:29:14 +0200 Subject: [rspec-devel] Test::Unit / RSpec package diagram Message-ID: <8d961d900709271529r1ef384bcv58587ff5d65da1a8@mail.gmail.com> I've checked in a package diagram describing dependencies the way I'd like them under doc/src/images. WDYT? Aslak From padraic.brady at yahoo.com Thu Sep 27 18:58:17 2007 From: padraic.brady at yahoo.com (=?iso-8859-1?Q?P=E1draic_Brady?=) Date: Thu, 27 Sep 2007 15:58:17 -0700 (PDT) Subject: [rspec-devel] RSpec for PHP Message-ID: <536138.12456.qm@web55311.mail.re4.yahoo.com> Happy to steal it for the slower moving PHP community ;-) Paddy P?draic Brady http://blog.astrumfutura.com http://www.patternsforphp.com OpenID Europe Foundation Member-Subscriber ----- Original Message ---- From: aslak hellesoy To: rspec-devel Sent: Wednesday, September 26, 2007 10:08:47 PM Subject: Re: [rspec-devel] RSpec for PHP On 9/26/07, P?draic Brady wrote: > > Hi all, > > I've been using RSpec for many months now while learning Ruby, and have > enjoyed following the BDD evolution. After recently returning to PHP (where > most of my work lies) I found the lack of RSpec to be a bitter pill. > > So in collaboration with another PHP developer we intend to start work on a > PHPSpec framework and convert a few natives here in the PHP community. We're > hoping Terry Chay doesn't notice until it's too late ;). > > Any comments, words of support, or suggestions are most appreciated. Passing > it by the list as an FYI. > All I have to say is AWESOME, even if I don't use PHP. Glad to have contributed to a valuable concept :-) Aslak > Best regards, > Paddy > P?draic Brady > > http://blog.astrumfutura.com > http://www.patternsforphp.com > OpenID Europe Foundation Member-Subscriber > > > ________________________________ > Building a website is a piece of cake. > Yahoo! Small Business gives you all the tools to get online. > _______________________________________________ > 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 ____________________________________________________________________________________ Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase. http://farechase.yahoo.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070927/9b67b8ee/attachment.html From noreply at rubyforge.org Thu Sep 27 22:26:21 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 27 Sep 2007 22:26:21 -0400 (EDT) Subject: [rspec-devel] [ rspec-Bugs-13411 ] & quot; ./script/generate rspec& quot; is freezing Message-ID: <20070928022621.58D4EA970003@rubyforge.org> Bugs item #13411, was opened at 2007-08-27 02:30 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13411&group_id=797 Category: rails plugin Group: None Status: Open Resolution: None Priority: 3 Submitted By: Scott Taylor (smtlaissezfaire) Assigned to: Nobody (None) >Summary: &quot;./script/generate rspec&quot; is freezing Initial Comment: Setup: Rails project (version 1.2.3), checked out in vendor/rails Rspec + rspec_on_rails trunk (rev 2537) checked out in vendor/plugins rspec gem, version 1.0.8 Mac OS X.4.10 (Am I missing anything else?) Bug: running "./script/generate rspec" first checks for the existence of the spec dir (which it finds), and then freezes. Oddly enough, running "rdebug ./script/generate rspec" allows the rest of the files to be created (after prompting), as usual. I've uploaded a screencast of the bug here: http://railsnewbie.com/files/script_generate_rspec.mov I would try debugging this myself, but obviously my debugger has an effect on the debugging! ---------------------------------------------------------------------- >Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-09-28 02:26 Message: Ah - so some new insight. Actually, this isn't a freeze, it just appears to be. It only occurs when the file to be generated is already present, and not identical(exists, but is different). Basically, the gets() routine seems to be called before the puts prompt occurs. Here is a little screen cast: http://railsnewbie.com/files/rspec_generator_bug2.mov This doesn't look like a bug with rspec - it looks like a bug with rails (or more likely my configuration). I'm having exactly the same thing with ./script/generate model ModelName when the file exists and is different. This ticket can be closed. ---------------------------------------------------------------------- Comment By: Scott Taylor (smtlaissezfaire) Date: 2007-08-27 15:12 Message: I wasn't sure which generators you were speaking of, so I tried a bunch (all of them seemed to work): euclid% ./script/generate model HelloWorld exists app/models/ exists test/unit/ exists test/fixtures/ create app/models/hello_world.rb create test/unit/hello_world_test.rb create test/fixtures/hello_worlds.yml exists db/migrate create db/migrate/075_create_hello_worlds.rb euclid% ./script/destroy model HelloWorld notempty db/migrate notempty db rm db/migrate/075_create_hello_worlds.rb rm test/fixtures/hello_worlds.yml rm test/unit/hello_world_test.rb rm app/models/hello_world.rb notempty test/fixtures notempty test notempty test/unit notempty test notempty app/models notempty app euclid% ./script/generate rspec_model HelloWorld exists app/models/ exists spec/models/ exists spec/fixtures/ create app/models/hello_world.rb create spec/fixtures/hello_worlds.yml create spec/models/hello_world_spec.rb exists db/migrate create db/migrate/075_create_hello_worlds.rb euclid% ./script/generate rspec_controller HelloWorld exists app/controllers/ exists app/helpers/ create app/views/hello_world exists spec/controllers/ exists spec/helpers/ create spec/views/hello_world create spec/controllers/hello_world_controller_spec.rb create spec/helpers/hello_world_helper_spec.rb create app/controllers/hello_world_controller.rb create app/helpers/hello_world_helper.rb euclid% ./script/destroy rspec_model HelloWorld notempty db/migrate notempty db rm db/migrate/075_create_hello_worlds.rb rm spec/models/hello_world_spec.rb rm spec/fixtures/hello_worlds.yml rm app/models/hello_world.rb notempty spec/fixtures notempty spec notempty spec/models notempty spec notempty app/models notempty app euclid% ./script/destroy rspec_controller HelloWorld rm app/helpers/hello_world_helper.rb rm app/controllers/hello_world_controller.rb rm spec/helpers/hello_world_helper_spec.rb rm spec/controllers/hello_world_controller_spec.rb rmdir spec/views/hello_world rmdir spec/views Directory not empty - script/../config/../spec/views euclid% ./script/generate rspec_scaffold HelloWorld exists app/models/ exists app/controllers/ exists app/helpers/ create app/views/hello_worlds exists spec/controllers/ exists spec/models/ exists spec/helpers/ exists spec/fixtures/ create spec/views/hello_worlds create spec/controllers/hello_worlds_controller_spec.rb create app/controllers/hello_worlds_controller.rb create spec/helpers/hello_worlds_helper_spec.rb create app/helpers/hello_worlds_helper.rb create app/views/hello_worlds/index.rhtml create app/views/hello_worlds/show.rhtml create app/views/hello_worlds/new.rhtml create app/views/hello_worlds/edit.rhtml create app/models/hello_world.rb create spec/fixtures/hello_worlds.yml create spec/models/hello_world_spec.rb create spec/views/hello_worlds/edit.rhtml_spec.rb create spec/views/hello_worlds/index.rhtml_spec.rb create spec/views/hello_worlds/new.rhtml_spec.rb create spec/views/hello_worlds/show.rhtml_spec.rb exists db/migrate create db/migrate/075_create_hello_worlds.rb route map.resources :hello_worlds euclid% ./script/destroy rspec_scaffold HelloWorld route map.resources :hello_worlds notempty db/migrate notempty db rm db/migrate/075_create_hello_worlds.rb rm spec/views/hello_worlds/show.rhtml_spec.rb rm spec/views/hello_worlds/new.rhtml_spec.rb rm spec/views/hello_worlds/index.rhtml_spec.rb rm spec/views/hello_worlds/edit.rhtml_spec.rb rm spec/models/hello_world_spec.rb rm spec/fixtures/hello_worlds.yml rm app/models/hello_world.rb rm app/views/hello_worlds/edit.rhtml rm app/views/hello_worlds/new.rhtml rm app/views/hello_worlds/show.rhtml rm app/views/hello_worlds/index.rhtml rm app/helpers/hello_worlds_helper.rb rm spec/helpers/hello_worlds_helper_spec.rb rm app/controllers/hello_worlds_controller.rb rm spec/controllers/hello_worlds_controller_spec.rb rmdir spec/views/hello_worlds rmdir spec/views Directory not empty - script/../config/../spec/views euclid% ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2007-08-27 06:54 Message: Can you confirm that this only happens for the rspec generator and none of the others? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13411&group_id=797 From noreply at rubyforge.org Fri Sep 28 12:39:59 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 28 Sep 2007 12:39:59 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-14304 ] Specify the controller request in the description options Message-ID: <20070928163959.4092D5240BD6@rubyforge.org> Feature Requests item #14304, was opened at 2007-09-28 16:39 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=14304&group_id=797 Category: rails plugin Group: None Status: Open Priority: 3 Submitted By: Jonathan Leighton (jonleighton) Assigned to: Nobody (None) Summary: Specify the controller request in the description options Initial Comment: I was experimenting with metaprogramming some of my examples, in order to keep my specs DRY, and I needed some way to programmatically specify what the request being tested was. I came up with this: describe ArticlesController, :request => { :get => :show, :id => 53 } do it "should find the article" do Article.expects(:find).with(53) send_request end end Here is my code: http://pastie.caboo.se/101764 I would be willing to make this into a patch if it sounds like a good idea? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=14304&group_id=797 From pergesu at gmail.com Fri Sep 28 21:29:35 2007 From: pergesu at gmail.com (Pat Maddox) Date: Fri, 28 Sep 2007 18:29:35 -0700 Subject: [rspec-devel] rspec + edge rails Message-ID: <810a540e0709281829k66726560j2d7663b0876a443d@mail.gmail.com> Is anyone successfully using rspec with edge rails? I just tried to get on edge today so that I can use activeresource, but first it complained that ActionView::Helpers::JavaScriptMacrosHelper doesn't exist anymore. So I took that reference out. Then it said that there's no "Test::Unit.run=" method, so I took that line out. Now it's leaving me with NameError in 'Person finding a person when the record exists should find the db record' undefined local variable or method `method_name' for [RSpec example]:# /Users/pergesu/twistage_trunk/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/model.rb:12:in `before_eval' ./script/spec:4: I'm pretty confused because the only reference to method_name anywhere in the rspec code is in method_missing in Spec::DSL::BehaviourEval::ModuleMethods. That's the entire error message btw, there's nothing else. So, any clues on where they're clashing? Pat From hughes.james at gmail.com Fri Sep 28 21:41:53 2007 From: hughes.james at gmail.com (James Hughes) Date: Fri, 28 Sep 2007 18:41:53 -0700 Subject: [rspec-devel] rspec + edge rails In-Reply-To: <810a540e0709281829k66726560j2d7663b0876a443d@mail.gmail.com> References: <810a540e0709281829k66726560j2d7663b0876a443d@mail.gmail.com> Message-ID: <765a2c230709281841t49852954o63d33622545e2cc5@mail.gmail.com> On 9/28/07, Pat Maddox wrote: > Is anyone successfully using rspec with edge rails? I just tried to > get on edge today so that I can use activeresource, but first it > complained that ActionView::Helpers::JavaScriptMacrosHelper doesn't > exist anymore. So I took that reference out. Then it said that > there's no "Test::Unit.run=" method, so I took that line out. Now > it's leaving me with > > NameError in 'Person finding a person when the record exists should > find the db record' > undefined local variable or method `method_name' for [RSpec > example]:# > /Users/pergesu/twistage_trunk/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/model.rb:12:in > `before_eval' > ./script/spec:4: > > I'm pretty confused because the only reference to method_name anywhere > in the rspec code is in method_missing in > Spec::DSL::BehaviourEval::ModuleMethods. > > That's the entire error message btw, there's nothing else. > > So, any clues on where they're clashing? > > Pat I'm using edge rails and rspec trunk and haven't seen these. Haven't really put that setup through it's paces yet, though. If you tell me what you are running to get that error printed I'll try the same thing here. James From pergesu at gmail.com Fri Sep 28 22:17:09 2007 From: pergesu at gmail.com (Pat Maddox) Date: Fri, 28 Sep 2007 19:17:09 -0700 Subject: [rspec-devel] rspec + edge rails In-Reply-To: <765a2c230709281841t49852954o63d33622545e2cc5@mail.gmail.com> References: <810a540e0709281829k66726560j2d7663b0876a443d@mail.gmail.com> <765a2c230709281841t49852954o63d33622545e2cc5@mail.gmail.com> Message-ID: <810a540e0709281917p779ce764sf126e137ff5acc73@mail.gmail.com> On 9/28/07, James Hughes wrote: > On 9/28/07, Pat Maddox wrote: > > Is anyone successfully using rspec with edge rails? I just tried to > > get on edge today so that I can use activeresource, but first it > > complained that ActionView::Helpers::JavaScriptMacrosHelper doesn't > > exist anymore. So I took that reference out. Then it said that > > there's no "Test::Unit.run=" method, so I took that line out. Now > > it's leaving me with > > > > NameError in 'Person finding a person when the record exists should > > find the db record' > > undefined local variable or method `method_name' for [RSpec > > example]:# > > /Users/pergesu/twistage_trunk/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/model.rb:12:in > > `before_eval' > > ./script/spec:4: > > > > I'm pretty confused because the only reference to method_name anywhere > > in the rspec code is in method_missing in > > Spec::DSL::BehaviourEval::ModuleMethods. > > > > That's the entire error message btw, there's nothing else. > > > > So, any clues on where they're clashing? > > > > Pat > > I'm using edge rails and rspec trunk and haven't seen these. Haven't > really put that setup through it's paces yet, though. If you tell me > what you are running to get that error printed I'll try the same thing > here. > > James > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > hrm. I was actually just starting a new app for testing purposes. Anyway, here are the steps (I'm doing a brand new one now) rails --database=sqlite3 test_app svn export http://svn.rubyonrails.org/rails/trunk/ rails (r7675) svn export svn://rubyforge.org/var/svn/rspec/tags/CURRENT/rspec (r2677) svn export svn://rubyforge.org/var/svn/rspec/tags/CURRENT/rspec_on_rails (r2677) I generated rspec and an rspec_model. Just added two columns, name and age. Here's the spec: describe Person do before(:each) do @person = Person.new :name => "Pat" end it "should have a name" do @person.name.should == "Pat" end end Running script/spec spec/model/person_spec.rb gives me /Users/pergesu/work/test_app/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:263:in `load_missing_constant': uninitialized constant ActionView::Helpers::JavaScriptMacrosHelper (NameError) from /Users/pergesu/work/test_app/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:453:in `const_missing' from /Users/pergesu/work/test_app/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/helper.rb:31 from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require' from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in `require' from /Users/pergesu/work/test_app/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:496:in `require' from /Users/pergesu/work/test_app/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:342:in `new_constants_in' from /Users/pergesu/work/test_app/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:496:in `require' from /Users/pergesu/work/test_app/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour.rb:8 ... 25 levels... from /Users/pergesu/work/test_app/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:49:in `prepare!' from /Users/pergesu/work/test_app/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:19:in `run' from /Users/pergesu/work/test_app/vendor/plugins/rspec/lib/spec/runner/command_line.rb:17:in `run' from ./script/spec:4 So I took out line 31 of helper.rb, run the spec again and get /Users/pergesu/work/test_app/vendor/plugins/rspec_on_rails/lib/spec/rails.rb:20: undefined method `run=' for Test::Unit:Module (NoMethodError) from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require' from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in `require' from /Users/pergesu/work/test_app/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:496:in `require' from /Users/pergesu/work/test_app/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:342:in `new_constants_in' from /Users/pergesu/work/test_app/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:496:in `require' from ./spec/models/../spec_helper.rb:5 from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require' from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in `require' from ./spec/models/person_spec.rb:1 from /Users/pergesu/work/test_app/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:106:in `load' from /Users/pergesu/work/test_app/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:106:in `load_specs' from /Users/pergesu/work/test_app/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:105:in `each' from /Users/pergesu/work/test_app/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:105:in `load_specs' from /Users/pergesu/work/test_app/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:49:in `prepare!' from /Users/pergesu/work/test_app/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:19:in `run' from /Users/pergesu/work/test_app/vendor/plugins/rspec/lib/spec/runner/command_line.rb:17:in `run' from ./script/spec:4 So I took out "Test::Unit.run = true" from rails.rb, run again and get baggio:~/work/test_app pergesu$ ./script/spec spec/models/person_spec.rb F 1) NameError in 'Person should have a name' undefined local variable or method `method_name' for [RSpec example]:# /Users/pergesu/work/test_app/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/model.rb:12:in `before_eval' ./script/spec:4: Finished in 0.015112 seconds 1 example, 1 failure What revisions do you have of rails and rspec? Pat From dchelimsky at gmail.com Fri Sep 28 22:21:51 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 28 Sep 2007 21:21:51 -0500 Subject: [rspec-devel] rspec + edge rails In-Reply-To: <810a540e0709281917p779ce764sf126e137ff5acc73@mail.gmail.com> References: <810a540e0709281829k66726560j2d7663b0876a443d@mail.gmail.com> <765a2c230709281841t49852954o63d33622545e2cc5@mail.gmail.com> <810a540e0709281917p779ce764sf126e137ff5acc73@mail.gmail.com> Message-ID: <57c63afe0709281921v3f0b7335ua6c4a51325ce1e4b@mail.gmail.com> On 9/28/07, Pat Maddox wrote: > On 9/28/07, James Hughes wrote: > > On 9/28/07, Pat Maddox wrote: > > > Is anyone successfully using rspec with edge rails? I just tried to > > > get on edge today so that I can use activeresource, but first it > > > complained that ActionView::Helpers::JavaScriptMacrosHelper doesn't > > > exist anymore. So I took that reference out. Then it said that > > > there's no "Test::Unit.run=" method, so I took that line out. Now > > > it's leaving me with > > > > > > NameError in 'Person finding a person when the record exists should > > > find the db record' > > > undefined local variable or method `method_name' for [RSpec > > > example]:# > > > /Users/pergesu/twistage_trunk/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/model.rb:12:in > > > `before_eval' > > > ./script/spec:4: > > > > > > I'm pretty confused because the only reference to method_name anywhere > > > in the rspec code is in method_missing in > > > Spec::DSL::BehaviourEval::ModuleMethods. > > > > > > That's the entire error message btw, there's nothing else. > > > > > > So, any clues on where they're clashing? > > > > > > Pat > > > > I'm using edge rails and rspec trunk and haven't seen these. Haven't > > really put that setup through it's paces yet, though. If you tell me > > what you are running to get that error printed I'll try the same thing > > here. > > > > James > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > hrm. I was actually just starting a new app for testing purposes. > Anyway, here are the steps (I'm doing a brand new one now) > > rails --database=sqlite3 test_app > svn export http://svn.rubyonrails.org/rails/trunk/ rails (r7675) > svn export svn://rubyforge.org/var/svn/rspec/tags/CURRENT/rspec (r2677) > svn export svn://rubyforge.org/var/svn/rspec/tags/CURRENT/rspec_on_rails (r2677) Hi Pat - CURRENT is the last release, not the trunk. You want to get edge rspec if you're using edge rails: svn export svn://rubyforge.org/var/svn/rspec/trunk/rspec svn export svn://rubyforge.org/var/svn/rspec/trunk/rspec_on_rails Cheers, David > > I generated rspec and an rspec_model. Just added two columns, name > and age. Here's the spec: > > describe Person do > before(:each) do > @person = Person.new :name => "Pat" > end > > it "should have a name" do > @person.name.should == "Pat" > end > end > > Running script/spec spec/model/person_spec.rb gives me > > /Users/pergesu/work/test_app/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:263:in > `load_missing_constant': uninitialized constant > ActionView::Helpers::JavaScriptMacrosHelper (NameError) > from /Users/pergesu/work/test_app/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:453:in > `const_missing' > from /Users/pergesu/work/test_app/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/helper.rb:31 > from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in > `gem_original_require' > from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in > `require' > from /Users/pergesu/work/test_app/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:496:in > `require' > from /Users/pergesu/work/test_app/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:342:in > `new_constants_in' > from /Users/pergesu/work/test_app/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:496:in > `require' > from /Users/pergesu/work/test_app/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour.rb:8 > ... 25 levels... > from /Users/pergesu/work/test_app/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:49:in > `prepare!' > from /Users/pergesu/work/test_app/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:19:in > `run' > from /Users/pergesu/work/test_app/vendor/plugins/rspec/lib/spec/runner/command_line.rb:17:in > `run' > from ./script/spec:4 > > > So I took out line 31 of helper.rb, run the spec again and get > > /Users/pergesu/work/test_app/vendor/plugins/rspec_on_rails/lib/spec/rails.rb:20: > undefined method `run=' for Test::Unit:Module (NoMethodError) > from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in > `gem_original_require' > from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in > `require' > from /Users/pergesu/work/test_app/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:496:in > `require' > from /Users/pergesu/work/test_app/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:342:in > `new_constants_in' > from /Users/pergesu/work/test_app/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:496:in > `require' > from ./spec/models/../spec_helper.rb:5 > from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in > `gem_original_require' > from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in > `require' > from ./spec/models/person_spec.rb:1 > from /Users/pergesu/work/test_app/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:106:in > `load' > from /Users/pergesu/work/test_app/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:106:in > `load_specs' > from /Users/pergesu/work/test_app/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:105:in > `each' > from /Users/pergesu/work/test_app/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:105:in > `load_specs' > from /Users/pergesu/work/test_app/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:49:in > `prepare!' > from /Users/pergesu/work/test_app/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:19:in > `run' > from /Users/pergesu/work/test_app/vendor/plugins/rspec/lib/spec/runner/command_line.rb:17:in > `run' > from ./script/spec:4 > > > So I took out "Test::Unit.run = true" from rails.rb, run again and get > > baggio:~/work/test_app pergesu$ ./script/spec spec/models/person_spec.rb > F > > 1) > NameError in 'Person should have a name' > undefined local variable or method `method_name' for [RSpec > example]:# > /Users/pergesu/work/test_app/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/model.rb:12:in > `before_eval' > ./script/spec:4: > > Finished in 0.015112 seconds > > 1 example, 1 failure > > What revisions do you have of rails and rspec? > > Pat > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From pergesu at gmail.com Fri Sep 28 22:27:37 2007 From: pergesu at gmail.com (Pat Maddox) Date: Fri, 28 Sep 2007 19:27:37 -0700 Subject: [rspec-devel] rspec + edge rails In-Reply-To: <57c63afe0709281921v3f0b7335ua6c4a51325ce1e4b@mail.gmail.com> References: <810a540e0709281829k66726560j2d7663b0876a443d@mail.gmail.com> <765a2c230709281841t49852954o63d33622545e2cc5@mail.gmail.com> <810a540e0709281917p779ce764sf126e137ff5acc73@mail.gmail.com> <57c63afe0709281921v3f0b7335ua6c4a51325ce1e4b@mail.gmail.com> Message-ID: <810a540e0709281927g52f9760ud158b053b17911cb@mail.gmail.com> On 9/28/07, David Chelimsky wrote: > On 9/28/07, Pat Maddox wrote: > > On 9/28/07, James Hughes wrote: > > > On 9/28/07, Pat Maddox wrote: > > > > Is anyone successfully using rspec with edge rails? I just tried to > Hi Pat - CURRENT is the last release, not the trunk. > > You want to get edge rspec if you're using edge rails: > > svn export svn://rubyforge.org/var/svn/rspec/trunk/rspec > svn export svn://rubyforge.org/var/svn/rspec/trunk/rspec_on_rails > > Cheers, > David > > > > > I generated rspec and an rspec_model. Just added two columns, name > > and age. Here's the spec: > > > > describe Person do > > before(:each) do > > @person = Person.new :name => "Pat" > > end > > > > it "should have a name" do > > @person.name.should == "Pat" > > end > > end > > > > Running script/spec spec/model/person_spec.rb gives me > > > > /Users/pergesu/work/test_app/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:263:in > > `load_missing_constant': uninitialized constant > > ActionView::Helpers::JavaScriptMacrosHelper (NameError) > > from /Users/pergesu/work/test_app/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:453:in > > `const_missing' > > from /Users/pergesu/work/test_app/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/helper.rb:31 > > from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in > > `gem_original_require' > > from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in > > `require' > > from /Users/pergesu/work/test_app/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:496:in > > `require' > > from /Users/pergesu/work/test_app/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:342:in > > `new_constants_in' > > from /Users/pergesu/work/test_app/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:496:in > > `require' > > from /Users/pergesu/work/test_app/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour.rb:8 > > ... 25 levels... > > from /Users/pergesu/work/test_app/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:49:in > > `prepare!' > > from /Users/pergesu/work/test_app/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:19:in > > `run' > > from /Users/pergesu/work/test_app/vendor/plugins/rspec/lib/spec/runner/command_line.rb:17:in > > `run' > > from ./script/spec:4 > > > > > > So I took out line 31 of helper.rb, run the spec again and get > > > > /Users/pergesu/work/test_app/vendor/plugins/rspec_on_rails/lib/spec/rails.rb:20: > > undefined method `run=' for Test::Unit:Module (NoMethodError) > > from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in > > `gem_original_require' > > from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in > > `require' > > from /Users/pergesu/work/test_app/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:496:in > > `require' > > from /Users/pergesu/work/test_app/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:342:in > > `new_constants_in' > > from /Users/pergesu/work/test_app/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:496:in > > `require' > > from ./spec/models/../spec_helper.rb:5 > > from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in > > `gem_original_require' > > from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in > > `require' > > from ./spec/models/person_spec.rb:1 > > from /Users/pergesu/work/test_app/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:106:in > > `load' > > from /Users/pergesu/work/test_app/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:106:in > > `load_specs' > > from /Users/pergesu/work/test_app/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:105:in > > `each' > > from /Users/pergesu/work/test_app/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:105:in > > `load_specs' > > from /Users/pergesu/work/test_app/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:49:in > > `prepare!' > > from /Users/pergesu/work/test_app/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:19:in > > `run' > > from /Users/pergesu/work/test_app/vendor/plugins/rspec/lib/spec/runner/command_line.rb:17:in > > `run' > > from ./script/spec:4 > > > > > > So I took out "Test::Unit.run = true" from rails.rb, run again and get > > > > baggio:~/work/test_app pergesu$ ./script/spec spec/models/person_spec.rb > > F > > > > 1) > > NameError in 'Person should have a name' > > undefined local variable or method `method_name' for [RSpec > > example]:# > > /Users/pergesu/work/test_app/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/model.rb:12:in > > `before_eval' > > ./script/spec:4: > > > > Finished in 0.015112 seconds > > > > 1 example, 1 failure > > > > What revisions do you have of rails and rspec? > > > > Pat > > _______________________________________________ > > 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 > grr, I'm retarded. thanks :) Pat From dchelimsky at gmail.com Fri Sep 28 22:30:39 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 28 Sep 2007 21:30:39 -0500 Subject: [rspec-devel] rspec + edge rails In-Reply-To: <810a540e0709281927g52f9760ud158b053b17911cb@mail.gmail.com> References: <810a540e0709281829k66726560j2d7663b0876a443d@mail.gmail.com> <765a2c230709281841t49852954o63d33622545e2cc5@mail.gmail.com> <810a540e0709281917p779ce764sf126e137ff5acc73@mail.gmail.com> <57c63afe0709281921v3f0b7335ua6c4a51325ce1e4b@mail.gmail.com> <810a540e0709281927g52f9760ud158b053b17911cb@mail.gmail.com> Message-ID: <57c63afe0709281930h7fca11ebh85c421f16c5deb7c@mail.gmail.com> On 9/28/07, Pat Maddox wrote: > On 9/28/07, David Chelimsky wrote: > > On 9/28/07, Pat Maddox wrote: > > > On 9/28/07, James Hughes wrote: > > > > On 9/28/07, Pat Maddox wrote: > > > > > Is anyone successfully using rspec with edge rails? I just tried to > > Hi Pat - CURRENT is the last release, not the trunk. > > > > You want to get edge rspec if you're using edge rails: > > > > svn export svn://rubyforge.org/var/svn/rspec/trunk/rspec > > svn export svn://rubyforge.org/var/svn/rspec/trunk/rspec_on_rails > > > > Cheers, > > David > > > > > > > > I generated rspec and an rspec_model. Just added two columns, name > > > and age. Here's the spec: > > > > > > describe Person do > > > before(:each) do > > > @person = Person.new :name => "Pat" > > > end > > > > > > it "should have a name" do > > > @person.name.should == "Pat" > > > end > > > end > > > > > > Running script/spec spec/model/person_spec.rb gives me > > > > > > /Users/pergesu/work/test_app/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:263:in > > > `load_missing_constant': uninitialized constant > > > ActionView::Helpers::JavaScriptMacrosHelper (NameError) > > > from /Users/pergesu/work/test_app/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:453:in > > > `const_missing' > > > from /Users/pergesu/work/test_app/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/helper.rb:31 > > > from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in > > > `gem_original_require' > > > from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in > > > `require' > > > from /Users/pergesu/work/test_app/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:496:in > > > `require' > > > from /Users/pergesu/work/test_app/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:342:in > > > `new_constants_in' > > > from /Users/pergesu/work/test_app/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:496:in > > > `require' > > > from /Users/pergesu/work/test_app/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour.rb:8 > > > ... 25 levels... > > > from /Users/pergesu/work/test_app/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:49:in > > > `prepare!' > > > from /Users/pergesu/work/test_app/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:19:in > > > `run' > > > from /Users/pergesu/work/test_app/vendor/plugins/rspec/lib/spec/runner/command_line.rb:17:in > > > `run' > > > from ./script/spec:4 > > > > > > > > > So I took out line 31 of helper.rb, run the spec again and get > > > > > > /Users/pergesu/work/test_app/vendor/plugins/rspec_on_rails/lib/spec/rails.rb:20: > > > undefined method `run=' for Test::Unit:Module (NoMethodError) > > > from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in > > > `gem_original_require' > > > from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in > > > `require' > > > from /Users/pergesu/work/test_app/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:496:in > > > `require' > > > from /Users/pergesu/work/test_app/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:342:in > > > `new_constants_in' > > > from /Users/pergesu/work/test_app/vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:496:in > > > `require' > > > from ./spec/models/../spec_helper.rb:5 > > > from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in > > > `gem_original_require' > > > from /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in > > > `require' > > > from ./spec/models/person_spec.rb:1 > > > from /Users/pergesu/work/test_app/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:106:in > > > `load' > > > from /Users/pergesu/work/test_app/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:106:in > > > `load_specs' > > > from /Users/pergesu/work/test_app/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:105:in > > > `each' > > > from /Users/pergesu/work/test_app/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:105:in > > > `load_specs' > > > from /Users/pergesu/work/test_app/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:49:in > > > `prepare!' > > > from /Users/pergesu/work/test_app/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:19:in > > > `run' > > > from /Users/pergesu/work/test_app/vendor/plugins/rspec/lib/spec/runner/command_line.rb:17:in > > > `run' > > > from ./script/spec:4 > > > > > > > > > So I took out "Test::Unit.run = true" from rails.rb, run again and get > > > > > > baggio:~/work/test_app pergesu$ ./script/spec spec/models/person_spec.rb > > > F > > > > > > 1) > > > NameError in 'Person should have a name' > > > undefined local variable or method `method_name' for [RSpec > > > example]:# > > > /Users/pergesu/work/test_app/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/model.rb:12:in > > > `before_eval' > > > ./script/spec:4: > > > > > > Finished in 0.015112 seconds > > > > > > 1 example, 1 failure > > > > > > What revisions do you have of rails and rspec? > > > > > > Pat > > > _______________________________________________ > > > 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 > > > > grr, I'm retarded. thanks :) np ps - your contributions to list of late have been extraordinarily eloquent and helpful. Not bad for a retarded guy ;) > > Pat > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dchelimsky at gmail.com Fri Sep 28 22:33:40 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 28 Sep 2007 21:33:40 -0500 Subject: [rspec-devel] rspec + edge rails In-Reply-To: <57c63afe0709281930h7fca11ebh85c421f16c5deb7c@mail.gmail.com> References: <810a540e0709281829k66726560j2d7663b0876a443d@mail.gmail.com> <765a2c230709281841t49852954o63d33622545e2cc5@mail.gmail.com> <810a540e0709281917p779ce764sf126e137ff5acc73@mail.gmail.com> <57c63afe0709281921v3f0b7335ua6c4a51325ce1e4b@mail.gmail.com> <810a540e0709281927g52f9760ud158b053b17911cb@mail.gmail.com> <57c63afe0709281930h7fca11ebh85c421f16c5deb7c@mail.gmail.com> Message-ID: <57c63afe0709281933i54aa6216o8545a0a411ccd68e@mail.gmail.com> On 9/28/07, David Chelimsky wrote: > ps - your contributions to list of late have been extraordinarily > eloquent and helpful. Not bad for a retarded guy ;) D'oh - "to *the* list" Oh, the irony. From dchelimsky at gmail.com Sat Sep 29 09:23:41 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 29 Sep 2007 08:23:41 -0500 Subject: [rspec-devel] structure for test/unit integration Message-ID: <57c63afe0709290623o2245c66dudd09047461be6d03@mail.gmail.com> Right now we have this: lib/spec/extensions/test/unit/etc spec/spec/test_unit/etc I'd like make these parallel but I'm not sure which structure to go with. Any thoughts about these three? (lib|spec)/spec/extensions/test/unit/etc (lib|spec)/spec/test/unit/etc (lib|spec)/test/unit/etc Cheers, David From aslak.hellesoy at gmail.com Sat Sep 29 10:01:08 2007 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sat, 29 Sep 2007 16:01:08 +0200 Subject: [rspec-devel] structure for test/unit integration In-Reply-To: <57c63afe0709290623o2245c66dudd09047461be6d03@mail.gmail.com> References: <57c63afe0709290623o2245c66dudd09047461be6d03@mail.gmail.com> Message-ID: <8d961d900709290701n6118a410madaf15d6b0b2bcac@mail.gmail.com> On 9/29/07, David Chelimsky wrote: > Right now we have this: > > lib/spec/extensions/test/unit/etc > spec/spec/test_unit/etc > > I'd like make these parallel but I'm not sure which structure to go > with. Any thoughts about these three? > > (lib|spec)/spec/extensions/test/unit/etc My initial suggestion, but too deep for my liking. > (lib|spec)/spec/test/unit/etc I like this one. Simple. > (lib|spec)/test/unit/etc > Can't use this one - it would conflict with the official test/unit. > Cheers, > David > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From brian.takita at gmail.com Sat Sep 29 15:17:47 2007 From: brian.takita at gmail.com (Brian Takita) Date: Sat, 29 Sep 2007 12:17:47 -0700 Subject: [rspec-devel] structure for test/unit integration In-Reply-To: <8d961d900709290701n6118a410madaf15d6b0b2bcac@mail.gmail.com> References: <57c63afe0709290623o2245c66dudd09047461be6d03@mail.gmail.com> <8d961d900709290701n6118a410madaf15d6b0b2bcac@mail.gmail.com> Message-ID: <1d7ddd110709291217p40e7ef72m54e7b077cddb65b5@mail.gmail.com> On 9/29/07, aslak hellesoy wrote: > On 9/29/07, David Chelimsky wrote: > > Right now we have this: > > > > lib/spec/extensions/test/unit/etc > > spec/spec/test_unit/etc > > > > I'd like make these parallel but I'm not sure which structure to go > > with. Any thoughts about these three? > > > > (lib|spec)/spec/extensions/test/unit/etc > > My initial suggestion, but too deep for my liking. > > > (lib|spec)/spec/test/unit/etc > > I like this one. Simple. I like that one too. > > > (lib|spec)/test/unit/etc > > > > Can't use this one - it would conflict with the official test/unit. > > > Cheers, > > David > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dchelimsky at gmail.com Sun Sep 30 10:56:14 2007 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 30 Sep 2007 09:56:14 -0500 Subject: [rspec-devel] structure for test/unit integration In-Reply-To: <1d7ddd110709291217p40e7ef72m54e7b077cddb65b5@mail.gmail.com> References: <57c63afe0709290623o2245c66dudd09047461be6d03@mail.gmail.com> <8d961d900709290701n6118a410madaf15d6b0b2bcac@mail.gmail.com> <1d7ddd110709291217p40e7ef72m54e7b077cddb65b5@mail.gmail.com> Message-ID: <57c63afe0709300756p7654698cp863e72323774e828@mail.gmail.com> On 9/29/07, Brian Takita wrote: > On 9/29/07, aslak hellesoy wrote: > > On 9/29/07, David Chelimsky wrote: > > > Right now we have this: > > > > > > lib/spec/extensions/test/unit/etc > > > spec/spec/test_unit/etc > > > > > > I'd like make these parallel but I'm not sure which structure to go > > > with. Any thoughts about these three? > > > > > > (lib|spec)/spec/extensions/test/unit/etc > > > > My initial suggestion, but too deep for my liking. > > > > (lib|spec)/spec/test/unit/etc > > > > I like this one. Simple. > I like that one too. Me too. Done. > > > > > (lib|spec)/test/unit/etc > > > > > > > Can't use this one - it would conflict with the official test/unit. > > > > > Cheers, > > > David > > > _______________________________________________ > > > rspec-devel mailing list > > > rspec-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From noreply at rubyforge.org Sun Sep 30 11:05:40 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 30 Sep 2007 11:05:40 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-14304 ] Specify the controller request in the description options Message-ID: <20070930150541.EC4FA5240B53@rubyforge.org> Feature Requests item #14304, was opened at 2007-09-28 16:39 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=14304&group_id=797 Category: rails plugin Group: None Status: Open Priority: 3 Submitted By: Jonathan Leighton (jonleighton) Assigned to: Nobody (None) Summary: Specify the controller request in the description options Initial Comment: I was experimenting with metaprogramming some of my examples, in order to keep my specs DRY, and I needed some way to programmatically specify what the request being tested was. I came up with this: describe ArticlesController, :request => { :get => :show, :id => 53 } do it "should find the article" do Article.expects(:find).with(53) send_request end end Here is my code: http://pastie.caboo.se/101764 I would be willing to make this into a patch if it sounds like a good idea? ---------------------------------------------------------------------- >Comment By: David Chelimsky (dchelimsky) Date: 2007-09-30 15:05 Message: It sounds like a good idea, but I'd like to get more feedback first. How about blogging it or releasing it as a plugin so people can get some experience with it. If the feedback is generally positive I'd be open to adding it. The only reason I'm not jumping on it is that I've been feeling as though RSpec has become too bloated as it is, and I'm hesitant to add any new features without careful consideration. It does sound like a good idea, and I'll be exploring it myself on my own projects. Cheers, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=14304&group_id=797 From noreply at rubyforge.org Sun Sep 30 21:16:29 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 30 Sep 2007 21:16:29 -0400 (EDT) Subject: [rspec-devel] [ rspec-Feature Requests-14304 ] Specify the controller request in the description options Message-ID: <20071001011629.AC7A0A970003@rubyforge.org> Feature Requests item #14304, was opened at 2007-09-28 11:39 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=14304&group_id=797 Category: rails plugin Group: None Status: Open Priority: 3 Submitted By: Jonathan Leighton (jonleighton) Assigned to: Nobody (None) Summary: Specify the controller request in the description options Initial Comment: I was experimenting with metaprogramming some of my examples, in order to keep my specs DRY, and I needed some way to programmatically specify what the request being tested was. I came up with this: describe ArticlesController, :request => { :get => :show, :id => 53 } do it "should find the article" do Article.expects(:find).with(53) send_request end end Here is my code: http://pastie.caboo.se/101764 I would be willing to make this into a patch if it sounds like a good idea? ---------------------------------------------------------------------- Comment By: Mike Mangino (mmangino) Date: 2007-09-30 20:16 Message: I don't care for this at all. If you want this behavior, you could easily define the send_request method yourself. It just seems like a really obscure syntax. I'd rather the action performed by send_request be made more explicit. ---------------------------------------------------------------------- Comment By: David Chelimsky (dchelimsky) Date: 2007-09-30 10:05 Message: It sounds like a good idea, but I'd like to get more feedback first. How about blogging it or releasing it as a plugin so people can get some experience with it. If the feedback is generally positive I'd be open to adding it. The only reason I'm not jumping on it is that I've been feeling as though RSpec has become too bloated as it is, and I'm hesitant to add any new features without careful consideration. It does sound like a good idea, and I'll be exploring it myself on my own projects. Cheers, David ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=14304&group_id=797