From ashley.moran at patchspace.co.uk Sun Aug 1 05:36:20 2010 From: ashley.moran at patchspace.co.uk (Ashley Moran) Date: Sun, 1 Aug 2010 10:36:20 +0100 Subject: [rspec-users] Evaluating shared example customisation block before shared block In-Reply-To: <4977696a-94a3-4467-9048-7c8845731a52@x18g2000pro.googlegroups.com> References: <30EC00AE-9668-48DC-9861-E234B7D87302@patchspace.co.uk> <09CFF5F4-E1F8-417E-9781-C264B44F8081@gmail.com> <92EF66E4-3748-462D-BC85-EEF0BF51C223@patchspace.co.uk> <2A82081A-ED3E-423B-A068-3FB067F8C4B6@gmail.com> <81E33C70-68CD-4415-BC9E-23D0F2B6F0FB@patchspace.co.uk> <621BAF47-4CEC-4364-B706-6DFF7C9155A1@gmail.com> <529E5DDF-1E2C-4F38-9DD4-DAD1350218FF@patchspace.co.uk> <4977696a-94a3-4467-9048-7c8845731a52@x18g2000pro.googlegroups.com> Message-ID: <2EE58339-BEB7-4BD4-B7B5-E8427D64DD07@patchspace.co.uk> On Jul 31, 2010, at 7:06 pm, Myron Marston wrote: > I think this is a clunky way to essentially pass a parameter to the > shared example group. Better would be something like this: > > it_should_behave_like "something" do > providing :method_name, :foo > end After sleeping on this, I found an elegant solution (elegant in Ruby 1.9 anyway, I had to monkeypatch Ruby 1.8 to make it work) to the class method problem. (It was exactly what I said before.) So I *think* all the technical problems for this feature are solved, and the question is just how the it should actually behave... Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran From dchelimsky at gmail.com Sun Aug 1 10:43:42 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 1 Aug 2010 09:43:42 -0500 Subject: [rspec-users] Evaluating shared example customisation block before shared block In-Reply-To: <4977696a-94a3-4467-9048-7c8845731a52@x18g2000pro.googlegroups.com> References: <30EC00AE-9668-48DC-9861-E234B7D87302@patchspace.co.uk> <09CFF5F4-E1F8-417E-9781-C264B44F8081@gmail.com> <92EF66E4-3748-462D-BC85-EEF0BF51C223@patchspace.co.uk> <2A82081A-ED3E-423B-A068-3FB067F8C4B6@gmail.com> <81E33C70-68CD-4415-BC9E-23D0F2B6F0FB@patchspace.co.uk> <621BAF47-4CEC-4364-B706-6DFF7C9155A1@gmail.com> <529E5DDF-1E2C-4F38-9DD4-DAD1350218FF@patchspace.co.uk> <4977696a-94a3-4467-9048-7c8845731a52@x18g2000pro.googlegroups.com> Message-ID: On Jul 31, 2010, at 1:06 PM, Myron Marston wrote: >> You can still get the same outcome, but you have to implement it in the group like this: > >> unless defined?(:foo) >> def foo; "foo"; end >> end > > Good point--I hadn't thought of that. The one issue I see with it is > that the author of the shared example group may not have knowledge of > which helper methods consumers will need to override. That's no different from methods that have default values for arguments: def foo(bar, baz = :default) If you provide only 1 arg, all is well, but the first one is required. Here's the same idea expressed in a group: shared_examples_for "foo" do unless defined?(:bar) raise "you need to supply a bar() method" end unless defined?(:baz) def baz; :default; end end end > So he/she > either defines all helper methods that way, or guesses about which > ones to define that way (and potentially guesses wrong). > >> Maybe a DSL method while I'm working on it? Maybe: >> >> default_helper(:foo) do >> "foo" >> end >> >> WDYT? > > If we go the route of having the customization block evaluated first, > then I like the idea, but I'm generally wary of adding more DSL > methods to RSpec. I think we should be careful to only add new DSL > methods that many people will find useful. If you find it useful, > it's very easy to use it in your project without it being part of > RSpec: just define default_helper in a module, and use config.extend > YourModule in the RSpec.configuration block. (Note that I'm _not_ > against adding this to RSpec: I just want to be sure we don't add a > bunch of DSL methods that have limited usefulness.) > > Looking back at the initial example that prompted the thread, it looks > to me like the primary use case for evaluating the customization block > first is so that you can parameterize the shared example group's > example descriptions. (There may be other use cases for defining a > class-level helper methods, but none springs to mind). I also do this > frequently. Often times I have something like this: > > [:foo, :bar, :baz].each do |method| > it "does something for #{method}" do > subject.send(method).should ... > end > end > > In this case I'm using the method parameter at the class level (to > interpolate into the description string) and at the instance level > (within the example itself). > > If we evaluated the customization block first, it would allow this, > but you'd have to define both an instance and class helper: > > it_should_behave_like "something" do > def self.method_name; :foo; end > def method_name; :foo; end > end > > I think this is a clunky way to essentially pass a parameter to the > shared example group. Better would be something like this: > > it_should_behave_like "something" do > providing :method_name, :foo > end > > The instance of the shared example group provides :foo as the value of > the method_name parameter. providing simply defines a class and an > instance helper method with the given value. > > I've written up an untested gist with a start for the code that would > implement this: > > http://gist.github.com/502409 > > I think there's value in evaluating the customization block first and > value in evaluating it last. We can get the best of both worlds if we > limit what's evaluated first to a subset (say, a few DSL methods, and > maybe all class method definitions), extract it, and evaluate that > first, then evaluate the shared block first, then evaluate the > customization block. The gist demonstrates this as well. This may > confuse people, but it does give us the best of both worlds, I think. Agreed on both points: best of both worlds and confusing :) When I said "maybe a DSL" I was thinking only in the context of the shared group, not in the consuming group. What makes the example in your gist confusing to me is that we start to get into a different mental model of what a shared group is. Based on recent changes, for me, it's just a nested example group, which has well understood scoping rules. This introduces a new set of scoping rules that not only make this use case confusing, but it will lead to an expectation that this DSL be made available in other constructs. The particular issue of simple values being used in the docstrings and the examples themselves (i.e. exposed to everything in the block scope) could be handled like this: shared_examples_for "blah" do |a,b| ... end it_should_behave_like "blah", 1, 2 That wouldn't have worked with the old implementation, but it would work perfectly well now. This would also "just work" with hash-as-keyword-args: shared_examples_for "blah" do |options| it "blah #{options[:a]}" do .. end end it_should_behave_like "blah", :a => 1 Now you can do this: [1,2,3].each do |n| it_should_behave_like "blah", :a => n end And we can still use the customization block to define methods, hooks (before/after) and let(). Now it just feels like the rest of RSpec. Thoughts? > > Myron > > > On Jul 31, 12:56 am, Ashley Moran > wrote: >> On 31 Jul 2010, at 1:10 AM, David Chelimsky wrote: >> >>> You can still get the same outcome, but you have to implement it in the group like this: >> >>> unless defined?(:foo) >>> def foo; "foo"; end >>> end >> >> Maybe a DSL method while I'm working on it? Maybe: >> >> default_helper(:foo) do >> "foo" >> end >> >> WDYT? >> >>> I think it's a good trade-off to put that burden on the group (and it's author) rather that the consumers of the group. >> >> Agreed, it'd cause a lot of duplication of effort the other way round. >> >> --http://www.patchspace.co.uk/http://www.linkedin.com/in/ashleymoran >> >> _______________________________________________ >> rspec-users mailing list >> rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users From dchelimsky at gmail.com Sun Aug 1 10:48:01 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 1 Aug 2010 09:48:01 -0500 Subject: [rspec-users] Evaluating shared example customisation block before shared block In-Reply-To: References: <30EC00AE-9668-48DC-9861-E234B7D87302@patchspace.co.uk> <09CFF5F4-E1F8-417E-9781-C264B44F8081@gmail.com> <92EF66E4-3748-462D-BC85-EEF0BF51C223@patchspace.co.uk> <2A82081A-ED3E-423B-A068-3FB067F8C4B6@gmail.com> <81E33C70-68CD-4415-BC9E-23D0F2B6F0FB@patchspace.co.uk> <621BAF47-4CEC-4364-B706-6DFF7C9155A1@gmail.com> <529E5DDF-1E2C-4F38-9DD4-DAD1350218FF@patchspace.co.uk> <4977696a-94a3-4467-9048-7c8845731a52@x18g2000pro.googlegroups.com> Message-ID: <29E710E3-0D15-4B39-8B2E-B2625065C310@gmail.com> On Aug 1, 2010, at 9:43 AM, David Chelimsky wrote: > > On Jul 31, 2010, at 1:06 PM, Myron Marston wrote: > >>> You can still get the same outcome, but you have to implement it in the group like this: >> >>> unless defined?(:foo) >>> def foo; "foo"; end >>> end >> >> Good point--I hadn't thought of that. The one issue I see with it is >> that the author of the shared example group may not have knowledge of >> which helper methods consumers will need to override. > > That's no different from methods that have default values for arguments: > > def foo(bar, baz = :default) > > If you provide only 1 arg, all is well, but the first one is required. Here's the same idea expressed in a group: > > shared_examples_for "foo" do > unless defined?(:bar) > raise "you need to supply a bar() method" > end > > unless defined?(:baz) > def baz; :default; end > end > end > >> So he/she >> either defines all helper methods that way, or guesses about which >> ones to define that way (and potentially guesses wrong). >> >>> Maybe a DSL method while I'm working on it? Maybe: >>> >>> default_helper(:foo) do >>> "foo" >>> end >>> >>> WDYT? >> >> If we go the route of having the customization block evaluated first, >> then I like the idea, but I'm generally wary of adding more DSL >> methods to RSpec. I think we should be careful to only add new DSL >> methods that many people will find useful. If you find it useful, >> it's very easy to use it in your project without it being part of >> RSpec: just define default_helper in a module, and use config.extend >> YourModule in the RSpec.configuration block. (Note that I'm _not_ >> against adding this to RSpec: I just want to be sure we don't add a >> bunch of DSL methods that have limited usefulness.) >> >> Looking back at the initial example that prompted the thread, it looks >> to me like the primary use case for evaluating the customization block >> first is so that you can parameterize the shared example group's >> example descriptions. (There may be other use cases for defining a >> class-level helper methods, but none springs to mind). I also do this >> frequently. Often times I have something like this: >> >> [:foo, :bar, :baz].each do |method| >> it "does something for #{method}" do >> subject.send(method).should ... >> end >> end >> >> In this case I'm using the method parameter at the class level (to >> interpolate into the description string) and at the instance level >> (within the example itself). >> >> If we evaluated the customization block first, it would allow this, >> but you'd have to define both an instance and class helper: >> >> it_should_behave_like "something" do >> def self.method_name; :foo; end >> def method_name; :foo; end >> end >> >> I think this is a clunky way to essentially pass a parameter to the >> shared example group. Better would be something like this: >> >> it_should_behave_like "something" do >> providing :method_name, :foo >> end >> >> The instance of the shared example group provides :foo as the value of >> the method_name parameter. providing simply defines a class and an >> instance helper method with the given value. >> >> I've written up an untested gist with a start for the code that would >> implement this: >> >> http://gist.github.com/502409 >> >> I think there's value in evaluating the customization block first and >> value in evaluating it last. We can get the best of both worlds if we >> limit what's evaluated first to a subset (say, a few DSL methods, and >> maybe all class method definitions), extract it, and evaluate that >> first, then evaluate the shared block first, then evaluate the >> customization block. The gist demonstrates this as well. This may >> confuse people, but it does give us the best of both worlds, I think. > > Agreed on both points: best of both worlds and confusing :) > > When I said "maybe a DSL" I was thinking only in the context of the shared group, not in the consuming group. > > What makes the example in your gist confusing to me is that we start to get into a different mental model of what a shared group is. Based on recent changes, for me, it's just a nested example group, which has well understood scoping rules. This introduces a new set of scoping rules that not only make this use case confusing, but it will lead to an expectation that this DSL be made available in other constructs. > > The particular issue of simple values being used in the docstrings and the examples themselves (i.e. exposed to everything in the block scope) could be handled like this: > > shared_examples_for "blah" do |a,b| > ... > end > > it_should_behave_like "blah", 1, 2 > > That wouldn't have worked with the old implementation, but it would work perfectly well now. This would also "just work" with hash-as-keyword-args: > > shared_examples_for "blah" do |options| > it "blah #{options[:a]}" do > .. > end > end > > it_should_behave_like "blah", :a => 1 > > Now you can do this: > > [1,2,3].each do |n| > it_should_behave_like "blah", :a => n > end > > And we can still use the customization block to define methods, hooks (before/after) and let(). Now it just feels like the rest of RSpec. Here's one way the measurement example could work in this format: http://gist.github.com/503432 > > Thoughts? > > > >> >> Myron >> >> >> On Jul 31, 12:56 am, Ashley Moran >> wrote: >>> On 31 Jul 2010, at 1:10 AM, David Chelimsky wrote: >>> >>>> You can still get the same outcome, but you have to implement it in the group like this: >>> >>>> unless defined?(:foo) >>>> def foo; "foo"; end >>>> end >>> >>> Maybe a DSL method while I'm working on it? Maybe: >>> >>> default_helper(:foo) do >>> "foo" >>> end >>> >>> WDYT? >>> >>>> I think it's a good trade-off to put that burden on the group (and it's author) rather that the consumers of the group. >>> >>> Agreed, it'd cause a lot of duplication of effort the other way round. >>> >>> --http://www.patchspace.co.uk/http://www.linkedin.com/in/ashleymoran >>> >>> _______________________________________________ >>> rspec-users mailing list >>> rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users > From myron.marston at gmail.com Sun Aug 1 12:40:19 2010 From: myron.marston at gmail.com (Myron Marston) Date: Sun, 1 Aug 2010 09:40:19 -0700 (PDT) Subject: [rspec-users] Evaluating shared example customisation block before shared block In-Reply-To: References: <30EC00AE-9668-48DC-9861-E234B7D87302@patchspace.co.uk> <09CFF5F4-E1F8-417E-9781-C264B44F8081@gmail.com> <92EF66E4-3748-462D-BC85-EEF0BF51C223@patchspace.co.uk> <2A82081A-ED3E-423B-A068-3FB067F8C4B6@gmail.com> <81E33C70-68CD-4415-BC9E-23D0F2B6F0FB@patchspace.co.uk> <621BAF47-4CEC-4364-B706-6DFF7C9155A1@gmail.com> <529E5DDF-1E2C-4F38-9DD4-DAD1350218FF@patchspace.co.uk> <4977696a-94a3-4467-9048-7c8845731a52@x18g2000pro.googlegroups.com> Message-ID: <26eb2d03-dc6f-4792-b77e-7e9bf08c1358@h17g2000pri.googlegroups.com> > The particular issue of simple values being used in the docstrings and the examples themselves (i.e. exposed to everything in the block scope) could be handled like this: > > shared_examples_for "blah" do |a,b| > ? ... > end > > it_should_behave_like "blah", 1, 2 Fantastic idea. I'm sold. I'm not sure why this simple idea didn't occur to me earlier :(. > That's no different from methods that have default values for arguments: > > ? def foo(bar, baz = :default) > > If you provide only 1 arg, all is well, but the first one is required. Here's the same idea expressed in a group: > > shared_examples_for "foo" do > ? unless defined?(:bar) > ? ? raise "you need to supply a bar() method" > ? end > > ? unless defined?(:baz) > ? ? def baz; :default; end > ? end > end This does indeed work, to the extent that the methods the consumer needs to override are ones the author of the shared example ground had in mind, and coded as such. This isn't an issue when the shared example group and the consuming code are in the same code base. But the idea has been brought up that shared example groups could be provided by a library for users to use to enforce a contract of some class or object they write that the library interacts with. I think it's likely that library authors won't declare their helper methods using the "unless defined?" idiom, because they can't anticipate all the needs of their users, and they probably aren't even aware that they have to declare their methods this way to allow them to be overridden. Suddenly it's _impossible_ for consumers of the shared example group to override any of the helper methods. I _love_ how flexible ruby is, and the fact that every method can be overridden, without the original author of the a method having to do anything special to allow it. Your suggestion above seems (to me anyway) to be more in line with a language like C#, where methods are not overriddable by default, and developers have to use the virtual keyword to make them so. So, all of that is just to say that I'm still in favor of eval'ing the customization block last. To me, the primary need for eval'ing the customization block first was to allow it define class helper methods that the shared example group could use to interpolate into doc strings, and this need is solved much more elegantly with David's suggestion. I like eval'ing it last so that helper methods can be overridden, _without_ anything special being done in the shared example group. Of course, if there are other things that will only work by eval'ing the block first, then I'm completely fine with it--I'm just not seeing the need right now. Myron From dchelimsky at gmail.com Sun Aug 1 15:02:21 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 1 Aug 2010 14:02:21 -0500 Subject: [rspec-users] Evaluating shared example customisation block before shared block In-Reply-To: <26eb2d03-dc6f-4792-b77e-7e9bf08c1358@h17g2000pri.googlegroups.com> References: <30EC00AE-9668-48DC-9861-E234B7D87302@patchspace.co.uk> <09CFF5F4-E1F8-417E-9781-C264B44F8081@gmail.com> <92EF66E4-3748-462D-BC85-EEF0BF51C223@patchspace.co.uk> <2A82081A-ED3E-423B-A068-3FB067F8C4B6@gmail.com> <81E33C70-68CD-4415-BC9E-23D0F2B6F0FB@patchspace.co.uk> <621BAF47-4CEC-4364-B706-6DFF7C9155A1@gmail.com> <529E5DDF-1E2C-4F38-9DD4-DAD1350218FF@patchspace.co.uk> <4977696a-94a3-4467-9048-7c8845731a52@x18g2000pro.googlegroups.com> <26eb2d03-dc6f-4792-b77e-7e9bf08c1358@h17g2000pri.googlegroups.com> Message-ID: <2AFB7F3E-FC58-4076-A44C-8FBACC4893B8@gmail.com> On Aug 1, 2010, at 11:40 AM, Myron Marston wrote: >> The particular issue of simple values being used in the docstrings and the examples themselves (i.e. exposed to everything in the block scope) could be handled like this: >> >> shared_examples_for "blah" do |a,b| >> ... >> end >> >> it_should_behave_like "blah", 1, 2 > > Fantastic idea. I'm sold. I'm not sure why this simple idea didn't > occur to me earlier :(. > >> That's no different from methods that have default values for arguments: >> >> def foo(bar, baz = :default) >> >> If you provide only 1 arg, all is well, but the first one is required. Here's the same idea expressed in a group: >> >> shared_examples_for "foo" do >> unless defined?(:bar) >> raise "you need to supply a bar() method" >> end >> >> unless defined?(:baz) >> def baz; :default; end >> end >> end > > This does indeed work, to the extent that the methods the consumer > needs to override are ones the author of the shared example ground had > in mind, and coded as such. This isn't an issue when the shared > example group and the consuming code are in the same code base. But > the idea has been brought up that shared example groups could be > provided by a library for users to use to enforce a contract of some > class or object they write that the library interacts with. I think > it's likely that library authors won't declare their helper methods > using the "unless defined?" idiom, because they can't anticipate all > the needs of their users, and they probably aren't even aware that > they have to declare their methods this way to allow them to be > overridden. I kind of jumped around from one part of this thread to the other - apologies if my responses seem to lack cohesion That would be the tricky gotta RTFM part - I'd rather have that burden on the shared group/library author than its consumer. > Suddenly it's _impossible_ for consumers of the shared > example group to override any of the helper methods. > > I _love_ how flexible ruby is, and the fact that every method can be > overridden, without the original author of the a method having to do > anything special to allow it. Your suggestion above seems (to me > anyway) to be more in line with a language like C#, where methods are > not overriddable by default, and developers have to use the virtual > keyword to make them so. Seems like your mental model is that of a customization block being a subclass or re-opening of the shared block. What you say makes sense in that model, but that's not the same model I have. If we were going to go with the subclass model, I think we'd be best served by going all the way there. So this structure: describe "foo" do it_behaves_like "bar", "with baz == 3" do def baz; 3 end end end Would result in: foo # top level group it behaves like bar # nested group generated by it_behaves_like using "bar" in the report with baz == 3 # 3rd level nested group generated using the customization block This would make the whole relationships between things much more transparent. I don't love this idea either, but we're searching for balance here. At least I am :) > So, all of that is just to say that I'm still in favor of eval'ing the > customization block last. To me, the primary need for eval'ing the > customization block first was to allow it define class helper methods > that the shared example group could use to interpolate into doc > strings, and this need is solved much more elegantly with David's > suggestion. Assuming that can work. I've taken a closer look and getting that to work would take some serious re-architecting that I'm not sure is a good idea. Consider the code as it is now: http://github.com/rspec/rspec-core/blob/cc72146205fb93ca11e1f290d3385151b51181ad/lib/rspec/core/example_group.rb#L61 I've restructured it a bit after some of this conversation, but right now the customization block is still eval'd last. I think this code is very easy to grok for a reasonably advanced Rubyist (i.e. if you can get past module_eval(<<-END_RUBY), then the content of the String is no problem), but if we start adding gymnastics to support various combinations of nice-to-haves, then this code will quickly become harder to read. In my experience with RSpec, readability/simplicity of the internals _does_ matter to end users, not just contributors and maintainers, because many want to understand what's going on under the hood. That is a strong motivator for me to keep things exactly as they are now (simple and readable). In terms of end-users, the consumer of the shared group would not need to be any different in either of these two scenarios: shared_examples_for "foo" do # with customization_block eval'd before unless defined?(:bar) raise "you need to supply a bar() method" end end shared_examples_for "foo" do # with customization_block eval'd after def bar raise "you need to supply a bar() method" end end In either case, this will get you the same error: it "does something" do it_behaves_like "bar" end > I like eval'ing it last so that helper methods can be > overridden, _without_ anything special being done in the shared > example group. I can appreciate that but I'd rather have burden placed on the shared group author than its consumer. Cheers, David > Of course, if there are other things that will only work by eval'ing > the block first, then I'm completely fine with it--I'm just not seeing > the need right now. > > Myron > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users From ashley.moran at patchspace.co.uk Sun Aug 1 18:12:40 2010 From: ashley.moran at patchspace.co.uk (Ashley Moran) Date: Sun, 1 Aug 2010 23:12:40 +0100 Subject: [rspec-users] Evaluating shared example customisation block before shared block In-Reply-To: References: <30EC00AE-9668-48DC-9861-E234B7D87302@patchspace.co.uk> <09CFF5F4-E1F8-417E-9781-C264B44F8081@gmail.com> <92EF66E4-3748-462D-BC85-EEF0BF51C223@patchspace.co.uk> <2A82081A-ED3E-423B-A068-3FB067F8C4B6@gmail.com> <81E33C70-68CD-4415-BC9E-23D0F2B6F0FB@patchspace.co.uk> <621BAF47-4CEC-4364-B706-6DFF7C9155A1@gmail.com> <529E5DDF-1E2C-4F38-9DD4-DAD1350218FF@patchspace.co.uk> <4977696a-94a3-4467-9048-7c8845731a52@x18g2000pro.googlegroups.com> Message-ID: On 1 Aug 2010, at 3:43 PM, David Chelimsky wrote: > shared_examples_for "blah" do |a,b| > ... > end > > it_should_behave_like "blah", 1, 2 > > That wouldn't have worked with the old implementation, but it would work perfectly well now. This would also "just work" with hash-as-keyword-args: > > shared_examples_for "blah" do |options| > it "blah #{options[:a]}" do > .. > end > end > > it_should_behave_like "blah", :a => 1 > > Now you can do this: > > [1,2,3].each do |n| > it_should_behave_like "blah", :a => n > end > > And we can still use the customization block to define methods, hooks (before/after) and let(). Now it just feels like the rest of RSpec. > > Thoughts? One thought: me.facepalm :) The only thing it lacks is a DSL to define the requirements. Would it still be desirable to be able to write: shared_examples_for "blah" do |options| require_argument options[:a] it "blah #{options[:a]}" do .. end end Or some such? Also, after staring at this for a while, I'm puzzled by something. In this code: it_should_behave_like "blah", :a => 1 how does :a => 1 get passed to the "options" block, as `shared_block` in the code is never called with arguments? Would this need another code change? (Apologies if I'm being thick, it's late and I should probably go to bed, but I wanted to review this first...) Cheers Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran From myron.marston at gmail.com Sun Aug 1 18:39:02 2010 From: myron.marston at gmail.com (Myron Marston) Date: Sun, 1 Aug 2010 15:39:02 -0700 (PDT) Subject: [rspec-users] Evaluating shared example customisation block before shared block In-Reply-To: <2AFB7F3E-FC58-4076-A44C-8FBACC4893B8@gmail.com> References: <30EC00AE-9668-48DC-9861-E234B7D87302@patchspace.co.uk> <09CFF5F4-E1F8-417E-9781-C264B44F8081@gmail.com> <92EF66E4-3748-462D-BC85-EEF0BF51C223@patchspace.co.uk> <2A82081A-ED3E-423B-A068-3FB067F8C4B6@gmail.com> <81E33C70-68CD-4415-BC9E-23D0F2B6F0FB@patchspace.co.uk> <621BAF47-4CEC-4364-B706-6DFF7C9155A1@gmail.com> <529E5DDF-1E2C-4F38-9DD4-DAD1350218FF@patchspace.co.uk> <4977696a-94a3-4467-9048-7c8845731a52@x18g2000pro.googlegroups.com> <26eb2d03-dc6f-4792-b77e-7e9bf08c1358@h17g2000pri.googlegroups.com> <2AFB7F3E-FC58-4076-A44C-8FBACC4893B8@gmail.com> Message-ID: > Seems like your mental model is that of a customization block being a subclass or re-opening of the shared block. What you say makes sense in that model, but that's not the same model I have. My mental model is indeed that the customization block is like a subclass. I'm not sure where I got it--it's just the intuitive way I understood shared_examples_for and it_should_behave_like. But if no one else shares this mental model, then there's not much point in making rspec work this way. I'm happy going with whatever the general consensus is. Although, I do think that my mental model makes for some interesting possibilities :). > Assuming that can work. I've taken a closer look and getting that to work would take some serious re-architecting that I'm not sure is a good idea. Maybe I misunderstood you here, but I took this to refer to the passing of parameters to the shared example group, as you suggested...and it turns out this isn't very hard at all: http://github.com/myronmarston/rspec-core/commit/c353badcb8154ab98a7dc46eb19c8a9fc702ec73 The one issue with this is that it uses #module_exec, which is not available in ruby 1.8.6--so we'd have to find a way to implement it, similar to how cucumber implements #instance_exec when it's not available: http://github.com/aslakhellesoy/cucumber/blob/30d43767a7cffd1675e990115ac86c139e4ea3e0/lib/cucumber/core_ext/instance_exec.rb#L16-31 Myron From dchelimsky at gmail.com Sun Aug 1 18:52:31 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 1 Aug 2010 17:52:31 -0500 Subject: [rspec-users] Evaluating shared example customisation block before shared block In-Reply-To: References: <30EC00AE-9668-48DC-9861-E234B7D87302@patchspace.co.uk> <09CFF5F4-E1F8-417E-9781-C264B44F8081@gmail.com> <92EF66E4-3748-462D-BC85-EEF0BF51C223@patchspace.co.uk> <2A82081A-ED3E-423B-A068-3FB067F8C4B6@gmail.com> <81E33C70-68CD-4415-BC9E-23D0F2B6F0FB@patchspace.co.uk> <621BAF47-4CEC-4364-B706-6DFF7C9155A1@gmail.com> <529E5DDF-1E2C-4F38-9DD4-DAD1350218FF@patchspace.co.uk> <4977696a-94a3-4467-9048-7c8845731a52@x18g2000pro.googlegroups.com> Message-ID: On Aug 1, 2010, at 5:12 PM, Ashley Moran wrote: > > On 1 Aug 2010, at 3:43 PM, David Chelimsky wrote: > >> shared_examples_for "blah" do |a,b| >> ... >> end >> >> it_should_behave_like "blah", 1, 2 >> >> That wouldn't have worked with the old implementation, but it would work perfectly well now. This would also "just work" with hash-as-keyword-args: >> >> shared_examples_for "blah" do |options| >> it "blah #{options[:a]}" do >> .. >> end >> end >> >> it_should_behave_like "blah", :a => 1 >> >> Now you can do this: >> >> [1,2,3].each do |n| >> it_should_behave_like "blah", :a => n >> end >> >> And we can still use the customization block to define methods, hooks (before/after) and let(). Now it just feels like the rest of RSpec. >> >> Thoughts? > > One thought: me.facepalm :) > > The only thing it lacks is a DSL to define the requirements. Would it still be desirable to be able to write: > > shared_examples_for "blah" do |options| > require_argument options[:a] > it "blah #{options[:a]}" do > .. > end > end > > Or some such? > > Also, after staring at this for a while, I'm puzzled by something. In this code: > > it_should_behave_like "blah", :a => 1 > > how does :a => 1 get passed to the "options" block, as `shared_block` in the code is never called with arguments? Would this need another code change? (Apologies if I'm being thick, it's late and I should probably go to bed, but I wanted to review this first...) Actually, I just discovered that ruby 1.8.7 actually added module_exec. What does this mean? It means this: def self.define_shared_group_method(new_name, report_label=nil) module_eval(<<-END_RUBY, __FILE__, __LINE__) def self.#{new_name}(name, *args, &customization_block) shared_block = world.shared_example_groups[name] raise "Could not find shared example group named \#{name.inspect}" unless shared_block describe("#{report_label || "it should behave like"} \#{name}") do module_exec *args, &shared_block module_exec *args, &customization_block if customization_block end end END_RUBY end What does that mean? It means this: shared_examples_for "foo" do |a,b,c| it "#{a} #{b} #{c}s" do a.should do_something_with(b, c) end end describe "something" do it_behaves_like "foo", 1, 2, 3 end Ta da!!!!!! Two problems to solve at this point: 1. order of evaluation of blocks 2. what to do about ruby 1.8.6 re: order of evaluation of blocks, I think I'm inclined to go one way one minute, and another the next. Somebody convince me of one or the other. re: 1.8.6, we've got a home-grown implementation of instance_exec that runs in 1.8.6 (although I just discovered that it's broken - fix coming shortly). I could a) add such a thing for module_exec as well, though I haven't quite figured out how that works yet. b) only support parameterized shared groups in ruby 1.8.7 or better c). the most drastic option, would be to drop support for 1.8.6 entirely, but I don't think that's really feasible yet. Thoughts? David > Cheers > Ash From dchelimsky at gmail.com Sun Aug 1 19:00:27 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 1 Aug 2010 18:00:27 -0500 Subject: [rspec-users] Evaluating shared example customisation block before shared block In-Reply-To: References: <30EC00AE-9668-48DC-9861-E234B7D87302@patchspace.co.uk> <09CFF5F4-E1F8-417E-9781-C264B44F8081@gmail.com> <92EF66E4-3748-462D-BC85-EEF0BF51C223@patchspace.co.uk> <2A82081A-ED3E-423B-A068-3FB067F8C4B6@gmail.com> <81E33C70-68CD-4415-BC9E-23D0F2B6F0FB@patchspace.co.uk> <621BAF47-4CEC-4364-B706-6DFF7C9155A1@gmail.com> <529E5DDF-1E2C-4F38-9DD4-DAD1350218FF@patchspace.co.uk> <4977696a-94a3-4467-9048-7c8845731a52@x18g2000pro.googlegroups.com> <26eb2d03-dc6f-4792-b77e-7e9bf08c1358@h17g2000pri.googlegroups.com> <2AFB7F3E-FC58-4076-A44C-8FBACC4893B8@gmail.com> Message-ID: <66873E67-895D-42BE-954C-AE6392088F44@gmail.com> On Aug 1, 2010, at 5:39 PM, Myron Marston wrote: >> Seems like your mental model is that of a customization block being a subclass or re-opening of the shared block. What you say makes sense in that model, but that's not the same model I have. > > My mental model is indeed that the customization block is like a > subclass. I'm not sure where I got it--it's just the intuitive way I > understood shared_examples_for and it_should_behave_like. But if no > one else shares this mental model, then there's not much point in > making rspec work this way. I'm happy going with whatever the general > consensus is. Although, I do think that my mental model makes for > some interesting possibilities :). > >> Assuming that can work. I've taken a closer look and getting that to work would take some serious re-architecting that I'm not sure is a good idea. > > Maybe I misunderstood you here, but I took this to refer to the > passing of parameters to the shared example group, as you > suggested...and it turns out this isn't very hard at all: > > http://github.com/myronmarston/rspec-core/commit/c353badcb8154ab98a7dc46eb19c8a9fc702ec73 If we do this, we should use module_exec for both blocks so they both get the same arguments. > > The one issue with this is that it uses #module_exec, which is not > available in ruby 1.8.6--so we'd have to find a way to implement it, > similar to how cucumber implements #instance_exec when it's not > available: > > http://github.com/aslakhellesoy/cucumber/blob/30d43767a7cffd1675e990115ac86c139e4ea3e0/lib/cucumber/core_ext/instance_exec.rb#L16-31 RSpec does that too :). Pretty sure it was Aslak that added that some years back. Yeah - I'm playing around with an implementation of module_exec, but it doesn't seem to work quite the same way as instance exec does. Not yet, anyhow. David > > Myron > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users From myron.marston at gmail.com Sun Aug 1 21:04:45 2010 From: myron.marston at gmail.com (Myron Marston) Date: Sun, 1 Aug 2010 18:04:45 -0700 (PDT) Subject: [rspec-users] Evaluating shared example customisation block before shared block In-Reply-To: References: <30EC00AE-9668-48DC-9861-E234B7D87302@patchspace.co.uk> <09CFF5F4-E1F8-417E-9781-C264B44F8081@gmail.com> <92EF66E4-3748-462D-BC85-EEF0BF51C223@patchspace.co.uk> <2A82081A-ED3E-423B-A068-3FB067F8C4B6@gmail.com> <81E33C70-68CD-4415-BC9E-23D0F2B6F0FB@patchspace.co.uk> <621BAF47-4CEC-4364-B706-6DFF7C9155A1@gmail.com> <529E5DDF-1E2C-4F38-9DD4-DAD1350218FF@patchspace.co.uk> <4977696a-94a3-4467-9048-7c8845731a52@x18g2000pro.googlegroups.com> Message-ID: <9e1b1173-212e-4117-a2b0-fb79752bf9b5@p11g2000prf.googlegroups.com> > If we do this, we should use module_exec for both blocks so they both get the same arguments. I actually find the use of this to be a bit confusing: [:foo, :bar].each do |arg| it_should_behave_like "Something", arg do |a| # The value of the param is already bound to arg and now it's bound to a, too. end end I suppose it may be useful in some situations, so I'm fine with it as long as the implementation allows you to skip the `|a|`: [:foo, :bar].each do |arg| it_should_behave_like "Something", arg do # no need to declare the |a| parameter since we already have it in arg. # I find this to be less confusing. end end > Actually, I just discovered that ruby 1.8.7 actually added module_exec. I should have mentioned that--my default ruby these days is 1.8.7, and I found the same thing. > re: order of evaluation of blocks, I think I'm inclined to go one way one minute, and another the next. Somebody convince me of one or the other. Maybe it would be useful to make a list of the things that are possible one way, but not the other, and vice versa...and then compare these lists. Which list has the more useful and commonly needed use cases? > a) add such a thing for module_exec as well, though I haven't quite figured out how that works yet. This is my vote. And I'm willing to take a stab at it--if for no other reason then it'll help increase my understanding of ruby :). I'm going to take a look at how rubinius implements this, and see what ruby specs there are for it. Myron From myron.marston at gmail.com Sun Aug 1 23:08:32 2010 From: myron.marston at gmail.com (Myron Marston) Date: Sun, 1 Aug 2010 20:08:32 -0700 (PDT) Subject: [rspec-users] Evaluating shared example customisation block before shared block In-Reply-To: <9e1b1173-212e-4117-a2b0-fb79752bf9b5@p11g2000prf.googlegroups.com> References: <30EC00AE-9668-48DC-9861-E234B7D87302@patchspace.co.uk> <09CFF5F4-E1F8-417E-9781-C264B44F8081@gmail.com> <92EF66E4-3748-462D-BC85-EEF0BF51C223@patchspace.co.uk> <2A82081A-ED3E-423B-A068-3FB067F8C4B6@gmail.com> <81E33C70-68CD-4415-BC9E-23D0F2B6F0FB@patchspace.co.uk> <621BAF47-4CEC-4364-B706-6DFF7C9155A1@gmail.com> <529E5DDF-1E2C-4F38-9DD4-DAD1350218FF@patchspace.co.uk> <4977696a-94a3-4467-9048-7c8845731a52@x18g2000pro.googlegroups.com> <9e1b1173-212e-4117-a2b0-fb79752bf9b5@p11g2000prf.googlegroups.com> Message-ID: OK, I tried to implement #module_exec on ruby 1.8.6, and here's what I came up with: http://github.com/myronmarston/rspec-core/commit/364f20ebd5b7d9612227cb6e86a6e8c8c2e9931e It works (at least in the sense that it allows the specs and features I added in the previous commits in that branch to pass on ruby 1.8.6), but I don't think it's correct. It just calls #instance_exec, but instance_exec and module_exec are not the same (at least as I understand them...). However, I based that implementation on rubinius 1.0.1's: http://github.com/evanphx/rubinius/blob/release-1.0.1/kernel/common/module.rb#L438-441 Backports (a library that implements features of later versions of ruby in 1.8.6) implements it in a similar fashion: http://github.com/marcandre/backports/blob/v1.18.1/lib/backports/1.8.7/module.rb Unfortunately, rubyspec doesn't provide much help in defining how module_exec should work: http://github.com/rubyspec/rubyspec/blob/master/core/module/module_exec_spec.rb I'd need some concrete examples demonstrating how module_exec should work (as compared to instance_exec) to implement it correctly. My understanding is that they are identical except in regards to method definitions--def's within an instance_exec define methods directly on the Module object instance, whereas def's within a module_exec define instance methods in the module (i.e. methods that will be added to any class that includes the module). One side issue I discovered is that instance_exec is implemented in rspec-expectations, but not rspec-core (which, incidentally, is why I linked to the cucumber implementation; I grepped in rspec-core and couldn't find it). instance_exec is already used in rspec-core: http://github.com/rspec/rspec-core/blob/v2.0.0.beta.19/lib/rspec/core/example_group.rb#L179 It needs to be implemented in rspec-core if you want rspec-core to be able to be used on 1.8.6 without rspec-expectations. Myron From ashley.moran at patchspace.co.uk Mon Aug 2 05:49:29 2010 From: ashley.moran at patchspace.co.uk (Ashley Moran) Date: Mon, 2 Aug 2010 10:49:29 +0100 Subject: [rspec-users] RSpec 2 Ruby 1.8.6 support (was Evaluating shared example customisation block before shared block) In-Reply-To: References: <30EC00AE-9668-48DC-9861-E234B7D87302@patchspace.co.uk> <09CFF5F4-E1F8-417E-9781-C264B44F8081@gmail.com> <92EF66E4-3748-462D-BC85-EEF0BF51C223@patchspace.co.uk> <2A82081A-ED3E-423B-A068-3FB067F8C4B6@gmail.com> <81E33C70-68CD-4415-BC9E-23D0F2B6F0FB@patchspace.co.uk> <621BAF47-4CEC-4364-B706-6DFF7C9155A1@gmail.com> <529E5DDF-1E2C-4F38-9DD4-DAD1350218FF@patchspace.co.uk> <4977696a-94a3-4467-9048-7c8845731a52@x18g2000pro.googlegroups.com> Message-ID: On Aug 01, 2010, at 11:52 pm, David Chelimsky wrote: > re: 1.8.6, we've got a home-grown implementation of instance_exec that runs in 1.8.6 (although I just discovered that it's broken - fix coming shortly). I could > > a) add such a thing for module_exec as well, though I haven't quite figured out how that works yet. > b) only support parameterized shared groups in ruby 1.8.7 or better > c). the most drastic option, would be to drop support for 1.8.6 entirely, but I don't think that's really feasible yet. Hmmm. If you're working on a Rails project with RSpec 2 (which I'm not, but I'm guessing that will be a very common case), you need 1.8.7 anyway, as Rails 3 won't run on anything less. If you're not using Rails, I can't imagine anyone starting a new project on 1.8.6 now. (All my new stuff is on 1.9.2.) Is 1.8.6 support in RSpec 2 *really* necessary? Any thoughts from anyone? Cheers Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran From dchelimsky at gmail.com Mon Aug 2 08:08:40 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 2 Aug 2010 07:08:40 -0500 Subject: [rspec-users] RSpec 2 Ruby 1.8.6 support (was Evaluating shared example customisation block before shared block) In-Reply-To: References: <30EC00AE-9668-48DC-9861-E234B7D87302@patchspace.co.uk> <09CFF5F4-E1F8-417E-9781-C264B44F8081@gmail.com> <92EF66E4-3748-462D-BC85-EEF0BF51C223@patchspace.co.uk> <2A82081A-ED3E-423B-A068-3FB067F8C4B6@gmail.com> <81E33C70-68CD-4415-BC9E-23D0F2B6F0FB@patchspace.co.uk> <621BAF47-4CEC-4364-B706-6DFF7C9155A1@gmail.com> <529E5DDF-1E2C-4F38-9DD4-DAD1350218FF@patchspace.co.uk> <4977696a-94a3-4467-9048-7c8845731a52@x18g2000pro.googlegroups.com> Message-ID: On Aug 2, 2010, at 4:49 AM, Ashley Moran wrote: > > On Aug 01, 2010, at 11:52 pm, David Chelimsky wrote: > >> re: 1.8.6, we've got a home-grown implementation of instance_exec that runs in 1.8.6 (although I just discovered that it's broken - fix coming shortly). I could >> >> a) add such a thing for module_exec as well, though I haven't quite figured out how that works yet. >> b) only support parameterized shared groups in ruby 1.8.7 or better >> c). the most drastic option, would be to drop support for 1.8.6 entirely, but I don't think that's really feasible yet. > > Hmmm. If you're working on a Rails project with RSpec 2 (which I'm not, but I'm guessing that will be a very common case), you need 1.8.7 anyway, as Rails 3 won't run on anything less. If you're not using Rails, I can't imagine anyone starting a new project on 1.8.6 now. (All my new stuff is on 1.9.2.) But what about people who are, for what ever reasons, stuck with Ruby 1.8.6 and want to upgrade? Also, there are a few rspec-2 + rails-2 efforts in the works, and there will be a solution for this sometime this fall. We need to support 1.8.6. > > Is 1.8.6 support in RSpec 2 *really* necessary? Any thoughts from anyone? > > Cheers > Ash > > -- > http://www.patchspace.co.uk/ > http://www.linkedin.com/in/ashleymoran > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users From rogerpack2005 at gmail.com Mon Aug 2 08:46:03 2010 From: rogerpack2005 at gmail.com (rogerdpack) Date: Mon, 2 Aug 2010 05:46:03 -0700 (PDT) Subject: [rspec-users] migration question Message-ID: <1eeb47b5-ac24-403c-beb9-ce78f2c53656@m35g2000prn.googlegroups.com> Got this: no such file to load -- spec/rake/spectask anybody know off hand what the equivalent is for rspec2? -r From dchelimsky at gmail.com Mon Aug 2 08:52:54 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 2 Aug 2010 07:52:54 -0500 Subject: [rspec-users] Evaluating shared example customisation block before shared block In-Reply-To: References: <30EC00AE-9668-48DC-9861-E234B7D87302@patchspace.co.uk> <09CFF5F4-E1F8-417E-9781-C264B44F8081@gmail.com> <92EF66E4-3748-462D-BC85-EEF0BF51C223@patchspace.co.uk> <2A82081A-ED3E-423B-A068-3FB067F8C4B6@gmail.com> <81E33C70-68CD-4415-BC9E-23D0F2B6F0FB@patchspace.co.uk> <621BAF47-4CEC-4364-B706-6DFF7C9155A1@gmail.com> <529E5DDF-1E2C-4F38-9DD4-DAD1350218FF@patchspace.co.uk> <4977696a-94a3-4467-9048-7c8845731a52@x18g2000pro.googlegroups.com> <9e1b1173-212e-4117-a2b0-fb79752bf9b5@p11g2000prf.googlegroups.com> Message-ID: On Aug 1, 2010, at 10:08 PM, Myron Marston wrote: > OK, I tried to implement #module_exec on ruby 1.8.6, and here's what I > came up with: > > http://github.com/myronmarston/rspec-core/commit/364f20ebd5b7d9612227cb6e86a6e8c8c2e9931e > > It works (at least in the sense that it allows the specs and features > I added in the previous commits in that branch to pass on ruby 1.8.6), > but I don't think it's correct. If we're not exposing this as an API, and we're only using it in order to support this feature in RSpec when running Ruby 1.8.6, and it solves our problem, then I think it's correct as it needs to be. > It just calls #instance_exec, but > instance_exec and module_exec are not the same (at least as I > understand them...). However, I based that implementation on rubinius > 1.0.1's: > > http://github.com/evanphx/rubinius/blob/release-1.0.1/kernel/common/module.rb#L438-441 > > Backports (a library that implements features of later versions of > ruby in 1.8.6) implements it in a similar fashion: > > http://github.com/marcandre/backports/blob/v1.18.1/lib/backports/1.8.7/module.rb > > Unfortunately, rubyspec doesn't provide much help in defining how > module_exec should work: > > http://github.com/rubyspec/rubyspec/blob/master/core/module/module_exec_spec.rb > > I'd need some concrete examples demonstrating how module_exec should > work (as compared to instance_exec) to implement it correctly. My > understanding is that they are identical except in regards to method > definitions--def's within an instance_exec define methods directly on > the Module object instance, whereas def's within a module_exec define > instance methods in the module (i.e. methods that will be added to any > class that includes the module). > > One side issue I discovered is that instance_exec is implemented in > rspec-expectations, but not rspec-core (which, incidentally, is why I > linked to the cucumber implementation; I grepped in rspec-core and > couldn't find it). instance_exec is already used in rspec-core: > > http://github.com/rspec/rspec-core/blob/v2.0.0.beta.19/lib/rspec/core/example_group.rb#L179 > > It needs to be implemented in rspec-core if you want rspec-core to be > able to be used on 1.8.6 without rspec-expectations. Done: http://github.com/rspec/rspec-core/commit/7d492bdc3657ca9472368b50f3f3f6635aca7fe0 > > Myron From ashley.moran at patchspace.co.uk Mon Aug 2 09:01:15 2010 From: ashley.moran at patchspace.co.uk (Ashley Moran) Date: Mon, 2 Aug 2010 14:01:15 +0100 Subject: [rspec-users] RSpec 2 Ruby 1.8.6 support (was Evaluating shared example customisation block before shared block) In-Reply-To: References: <30EC00AE-9668-48DC-9861-E234B7D87302@patchspace.co.uk> <09CFF5F4-E1F8-417E-9781-C264B44F8081@gmail.com> <92EF66E4-3748-462D-BC85-EEF0BF51C223@patchspace.co.uk> <2A82081A-ED3E-423B-A068-3FB067F8C4B6@gmail.com> <81E33C70-68CD-4415-BC9E-23D0F2B6F0FB@patchspace.co.uk> <621BAF47-4CEC-4364-B706-6DFF7C9155A1@gmail.com> <529E5DDF-1E2C-4F38-9DD4-DAD1350218FF@patchspace.co.uk> <4977696a-94a3-4467-9048-7c8845731a52@x18g2000pro.googlegroups.com> Message-ID: <8A47071E-531D-4BC7-B0B4-C61A61CA844A@patchspace.co.uk> On 2 Aug 2010, at 1:08 PM, David Chelimsky wrote: > But what about people who are, for what ever reasons, stuck with Ruby 1.8.6 and want to upgrade? Also, there are a few rspec-2 + rails-2 efforts in the works, and there will be a solution for this sometime this fall. > > We need to support 1.8.6. Ah fair enough. I didn't imagine there were many people stuck in that situation - I thought 1.8.6 was largely obsolete now. I also didn't know there were any RSpec-2/Rails-2 solutions in progress, I thought that was going to be unsupported. -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran From dchelimsky at gmail.com Mon Aug 2 09:09:10 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 2 Aug 2010 08:09:10 -0500 Subject: [rspec-users] migration question In-Reply-To: <1eeb47b5-ac24-403c-beb9-ce78f2c53656@m35g2000prn.googlegroups.com> References: <1eeb47b5-ac24-403c-beb9-ce78f2c53656@m35g2000prn.googlegroups.com> Message-ID: <3BE7819C-E2E1-4ABA-912B-E870E191D113@gmail.com> On Aug 2, 2010, at 7:46 AM, rogerdpack wrote: > Got this: > > no such file to load -- spec/rake/spectask > > anybody know off hand what the equivalent is for rspec2? rspec/core/rake_task I'll add that to Upgrade.markdown > -r > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users From dchelimsky at gmail.com Mon Aug 2 09:15:33 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 2 Aug 2010 08:15:33 -0500 Subject: [rspec-users] migration question In-Reply-To: <3BE7819C-E2E1-4ABA-912B-E870E191D113@gmail.com> References: <1eeb47b5-ac24-403c-beb9-ce78f2c53656@m35g2000prn.googlegroups.com> <3BE7819C-E2E1-4ABA-912B-E870E191D113@gmail.com> Message-ID: <9318D451-6CD8-4837-948D-1D713EE1B7EB@gmail.com> On Aug 2, 2010, at 8:09 AM, David Chelimsky wrote: > > On Aug 2, 2010, at 7:46 AM, rogerdpack wrote: > >> Got this: >> >> no such file to load -- spec/rake/spectask >> >> anybody know off hand what the equivalent is for rspec2? > > rspec/core/rake_task > > I'll add that to Upgrade.markdown http://github.com/rspec/rspec-core/blob/master/Upgrade.markdown > >> -r >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users > From ashley.moran at patchspace.co.uk Mon Aug 2 09:16:33 2010 From: ashley.moran at patchspace.co.uk (Ashley Moran) Date: Mon, 2 Aug 2010 14:16:33 +0100 Subject: [rspec-users] Evaluating shared example customisation block before shared block In-Reply-To: <9e1b1173-212e-4117-a2b0-fb79752bf9b5@p11g2000prf.googlegroups.com> References: <30EC00AE-9668-48DC-9861-E234B7D87302@patchspace.co.uk> <09CFF5F4-E1F8-417E-9781-C264B44F8081@gmail.com> <92EF66E4-3748-462D-BC85-EEF0BF51C223@patchspace.co.uk> <2A82081A-ED3E-423B-A068-3FB067F8C4B6@gmail.com> <81E33C70-68CD-4415-BC9E-23D0F2B6F0FB@patchspace.co.uk> <621BAF47-4CEC-4364-B706-6DFF7C9155A1@gmail.com> <529E5DDF-1E2C-4F38-9DD4-DAD1350218FF@patchspace.co.uk> <4977696a-94a3-4467-9048-7c8845731a52@x18g2000pro.googlegroups.com> <9e1b1173-212e-4117-a2b0-fb79752bf9b5@p11g2000prf.googlegroups.com> Message-ID: <1DEB077F-8400-44BB-BD2F-F6D72089941F@patchspace.co.uk> On 2 Aug 2010, at 2:04 AM, Myron Marston wrote: > I actually find the use of this to be a bit confusing: > > [:foo, :bar].each do |arg| > it_should_behave_like "Something", arg do |a| > # The value of the param is already bound to arg and now it's > bound to a, too. > end > end > > I suppose it may be useful in some situations, so I'm fine with it as > long as the implementation allows you to skip the `|a|`: > > [:foo, :bar].each do |arg| > it_should_behave_like "Something", arg do > # no need to declare the |a| parameter since we already have it in > arg. > # I find this to be less confusing. > end > end Agreed - requiring the block parameter to be declared in the host group is putting the onus back on the user, not the author, of the shared examples. I think we need a way to implement the second version. Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran From ashley.moran at patchspace.co.uk Mon Aug 2 09:19:59 2010 From: ashley.moran at patchspace.co.uk (Ashley Moran) Date: Mon, 2 Aug 2010 14:19:59 +0100 Subject: [rspec-users] Evaluating shared example customisation block before shared block In-Reply-To: References: <30EC00AE-9668-48DC-9861-E234B7D87302@patchspace.co.uk> <09CFF5F4-E1F8-417E-9781-C264B44F8081@gmail.com> <92EF66E4-3748-462D-BC85-EEF0BF51C223@patchspace.co.uk> <2A82081A-ED3E-423B-A068-3FB067F8C4B6@gmail.com> <81E33C70-68CD-4415-BC9E-23D0F2B6F0FB@patchspace.co.uk> <621BAF47-4CEC-4364-B706-6DFF7C9155A1@gmail.com> <529E5DDF-1E2C-4F38-9DD4-DAD1350218FF@patchspace.co.uk> <4977696a-94a3-4467-9048-7c8845731a52@x18g2000pro.googlegroups.com> <9e1b1173-212e-4117-a2b0-fb79752bf9b5@p11g2000prf.googlegroups.com> Message-ID: <96ECD777-5302-4597-ABBE-C45F88A8D0E3@patchspace.co.uk> On 2 Aug 2010, at 4:08 AM, Myron Marston wrote: > Backports (a library that implements features of later versions of > ruby in 1.8.6) implements it in a similar fashion: > > http://github.com/marcandre/backports/blob/v1.18.1/lib/backports/1.8.7/module.rb Conceivably, RSpec 2 could depend on Backports under Ruby 1.8.6. It's not my opinion that it should (I don't have one), but I'm interested to know the implications. Would that solve any design problems inside RSpec? Would that cause any problems for users? Would the problems solved outweigh the problems used? Cheers Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran From ashley.moran at patchspace.co.uk Mon Aug 2 09:23:20 2010 From: ashley.moran at patchspace.co.uk (Ashley Moran) Date: Mon, 2 Aug 2010 14:23:20 +0100 Subject: [rspec-users] Evaluating shared example customisation block before shared block In-Reply-To: References: <30EC00AE-9668-48DC-9861-E234B7D87302@patchspace.co.uk> <09CFF5F4-E1F8-417E-9781-C264B44F8081@gmail.com> <92EF66E4-3748-462D-BC85-EEF0BF51C223@patchspace.co.uk> <2A82081A-ED3E-423B-A068-3FB067F8C4B6@gmail.com> <81E33C70-68CD-4415-BC9E-23D0F2B6F0FB@patchspace.co.uk> <621BAF47-4CEC-4364-B706-6DFF7C9155A1@gmail.com> <529E5DDF-1E2C-4F38-9DD4-DAD1350218FF@patchspace.co.uk> <4977696a-94a3-4467-9048-7c8845731a52@x18g2000pro.googlegroups.com> Message-ID: On 1 Aug 2010, at 11:52 PM, David Chelimsky wrote: > re: order of evaluation of blocks, I think I'm inclined to go one way one minute, and another the next. Somebody convince me of one or the other. One thing that may help clear this up is: can anyone offer a concrete example of where overriding a shared example group helper method would be useful (and better than an alternative design)? My gut feeling is that, as David suggested, being able to override these is creating a class hierarchy of example groups. It feels to me unnervingly like overriding private methods. I wait to be proved wrong though, I just can't think of an example myself of wanting to do this. Cheers Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran From elliot.winkler at gmail.com Mon Aug 2 09:52:54 2010 From: elliot.winkler at gmail.com (Elliot Winkler) Date: Mon, 02 Aug 2010 08:52:54 -0500 Subject: [rspec-users] Newbie : How to spec params hash amendment In-Reply-To: <9bca94b8-b2eb-488a-b81b-8c04a56b5cbe@l14g2000yql.googlegroups.com> References: <9bca94b8-b2eb-488a-b81b-8c04a56b5cbe@l14g2000yql.googlegroups.com> Message-ID: <4C56CDB6.1000109@gmail.com> On 7/30/10 5:53 AM, Martin Hawkins wrote: > I have no idea how to approach 'rspec'ing the creation of the > params[:user][:password] and :password_confirmation or the > random_password method and would very much appreciate it if somebody > could spare the time to suggest what I should be doing. You could stub the random_password method with some value, then perform the create action, then confirm that the @user variable has that value for password and password_confirmation. (I forget if instance variables are accessible in a controller test even after a redirect, so I guess you'll find out.) -- Elliot From codehacker at comcast.net Mon Aug 2 19:22:56 2010 From: codehacker at comcast.net (LesNightingill) Date: Mon, 2 Aug 2010 16:22:56 -0700 (PDT) Subject: [rspec-users] Controller spec, integrate views, mocking helper method Message-ID: <36991143-3e81-43aa-a61e-2b8b4c7193c9@t2g2000yqe.googlegroups.com> I need to use integrate views to test some particular features. In ApplicationHelper I have: module ApplicationHelper def current_user_permitted? # some logic that returns true/false end end I'm testing MyController using Rspec/flexmock... describe MyController do integrate_views before(:each) do # how can I mock the 'current_user_permitted?' method here ? get :index end it "should display blah blah" do response.should have_tag('div#foo') do with_tag('div#bar',{:html => (/blah blah/)} ) end end end I've found that I can make the test pass by mocking the current_user_permitted? like this (BOTH mocks required in order to pass!): flexmock(ActionView::Base).new_instances.should_receive("current_user_permitted?").and_return(true) flexmock(controller, 'current_user_permitted?' => true) but this (2 mocks) just doesn't seem right, what is the right way? thanks in advance for any insight you can offer Les From myron.marston at gmail.com Mon Aug 2 22:33:19 2010 From: myron.marston at gmail.com (Myron Marston) Date: Mon, 2 Aug 2010 19:33:19 -0700 (PDT) Subject: [rspec-users] migration question In-Reply-To: <3BE7819C-E2E1-4ABA-912B-E870E191D113@gmail.com> References: <1eeb47b5-ac24-403c-beb9-ce78f2c53656@m35g2000prn.googlegroups.com> <3BE7819C-E2E1-4ABA-912B-E870E191D113@gmail.com> Message-ID: This may be useful for folks migrating... I recently updated one of my projects to RSpec 2. Here's the commit with all the changes: http://github.com/myronmarston/vcr/commit/f05cc59abc16b711e345bab2994ad2ebfdce7170 Summary: - Updated rakefile so it defines new spec tasks - Migrated simple_matcher to RSpec::Matchers.define - Removed spec.opts - Require 'rspec' rather than 'spec' - RSpec.configure rather than Spec::Runner.configure On Aug 2, 6:09?am, David Chelimsky wrote: > On Aug 2, 2010, at 7:46 AM, rogerdpack wrote: > > > Got this: > > > no such file to load -- spec/rake/spectask > > > anybody know off hand what the equivalent is for rspec2? > > rspec/core/rake_task > > I'll add that to Upgrade.markdown > > > -r > > _______________________________________________ > > rspec-users mailing list > > rspec-us... at rubyforge.org > >http://rubyforge.org/mailman/listinfo/rspec-users > > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users From dchelimsky at gmail.com Tue Aug 3 07:22:28 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 3 Aug 2010 06:22:28 -0500 Subject: [rspec-users] Evaluating shared example customisation block before shared block In-Reply-To: References: <30EC00AE-9668-48DC-9861-E234B7D87302@patchspace.co.uk> <09CFF5F4-E1F8-417E-9781-C264B44F8081@gmail.com> <92EF66E4-3748-462D-BC85-EEF0BF51C223@patchspace.co.uk> <2A82081A-ED3E-423B-A068-3FB067F8C4B6@gmail.com> <81E33C70-68CD-4415-BC9E-23D0F2B6F0FB@patchspace.co.uk> <621BAF47-4CEC-4364-B706-6DFF7C9155A1@gmail.com> <529E5DDF-1E2C-4F38-9DD4-DAD1350218FF@patchspace.co.uk> <4977696a-94a3-4467-9048-7c8845731a52@x18g2000pro.googlegroups.com> <9e1b1173-212e-4117-a2b0-fb79752bf9b5@p11g2000prf.googlegroups.com> Message-ID: On Aug 2, 2010, at 7:52 AM, David Chelimsky wrote: > On Aug 1, 2010, at 10:08 PM, Myron Marston wrote: > >> OK, I tried to implement #module_exec on ruby 1.8.6, and here's what I >> came up with: >> >> http://github.com/myronmarston/rspec-core/commit/364f20ebd5b7d9612227cb6e86a6e8c8c2e9931e >> >> It works (at least in the sense that it allows the specs and features >> I added in the previous commits in that branch to pass on ruby 1.8.6), >> but I don't think it's correct. > > If we're not exposing this as an API, and we're only using it in order to support this feature in RSpec when running Ruby 1.8.6, and it solves our problem, then I think it's correct as it needs to be. These are all true except for the "and it solves our problem" part. It almost does, but the one missing piece is that methods defined in the shared group are not available to its examples: shared_examples_for "thing" do def thing; Thing.new; do it "does something" do thing.should do_something end end My inclination is to get this feature out with explicit non-support for 1.8.6, and then add support for 1.8.6 if we can get this to work. Working on that now - should be pushing some code (including Myron's contribution) later today. Cheers, David > >> It just calls #instance_exec, but >> instance_exec and module_exec are not the same (at least as I >> understand them...). However, I based that implementation on rubinius >> 1.0.1's: >> >> http://github.com/evanphx/rubinius/blob/release-1.0.1/kernel/common/module.rb#L438-441 >> >> Backports (a library that implements features of later versions of >> ruby in 1.8.6) implements it in a similar fashion: >> >> http://github.com/marcandre/backports/blob/v1.18.1/lib/backports/1.8.7/module.rb >> >> Unfortunately, rubyspec doesn't provide much help in defining how >> module_exec should work: >> >> http://github.com/rubyspec/rubyspec/blob/master/core/module/module_exec_spec.rb >> >> I'd need some concrete examples demonstrating how module_exec should >> work (as compared to instance_exec) to implement it correctly. My >> understanding is that they are identical except in regards to method >> definitions--def's within an instance_exec define methods directly on >> the Module object instance, whereas def's within a module_exec define >> instance methods in the module (i.e. methods that will be added to any >> class that includes the module). >> >> One side issue I discovered is that instance_exec is implemented in >> rspec-expectations, but not rspec-core (which, incidentally, is why I >> linked to the cucumber implementation; I grepped in rspec-core and >> couldn't find it). instance_exec is already used in rspec-core: >> >> http://github.com/rspec/rspec-core/blob/v2.0.0.beta.19/lib/rspec/core/example_group.rb#L179 >> >> It needs to be implemented in rspec-core if you want rspec-core to be >> able to be used on 1.8.6 without rspec-expectations. > > Done: http://github.com/rspec/rspec-core/commit/7d492bdc3657ca9472368b50f3f3f6635aca7fe0 > >> >> Myron > From lists at ruby-forum.com Tue Aug 3 07:34:55 2010 From: lists at ruby-forum.com (Bruno Cardoso) Date: Tue, 3 Aug 2010 13:34:55 +0200 Subject: [rspec-users] [RSpec] Testing a helper with or without model layer? Message-ID: <826a4a227b246c16f7392878b335a257@ruby-forum.com> Hi guys, I wanted to get a more experienced opinion about a test I had to do. I posted the code at pastie with comments for best visual readability: http://pastie.org/private/qvvrxubslvia2nv6l3km4q Any feedback is appreciated Thanks -- Posted via http://www.ruby-forum.com/. From ashley.moran at patchspace.co.uk Tue Aug 3 07:43:05 2010 From: ashley.moran at patchspace.co.uk (Ashley Moran) Date: Tue, 3 Aug 2010 12:43:05 +0100 Subject: [rspec-users] Evaluating shared example customisation block before shared block In-Reply-To: References: <30EC00AE-9668-48DC-9861-E234B7D87302@patchspace.co.uk> <09CFF5F4-E1F8-417E-9781-C264B44F8081@gmail.com> <92EF66E4-3748-462D-BC85-EEF0BF51C223@patchspace.co.uk> <2A82081A-ED3E-423B-A068-3FB067F8C4B6@gmail.com> <81E33C70-68CD-4415-BC9E-23D0F2B6F0FB@patchspace.co.uk> <621BAF47-4CEC-4364-B706-6DFF7C9155A1@gmail.com> <529E5DDF-1E2C-4F38-9DD4-DAD1350218FF@patchspace.co.uk> <4977696a-94a3-4467-9048-7c8845731a52@x18g2000pro.googlegroups.com> <9e1b1173-212e-4117-a2b0-fb79752bf9b5@p11g2000prf.googlegroups.com> Message-ID: <3B1DB6C1-87E5-44F8-9E59-B23C66ED02C9@patchspace.co.uk> On Aug 03, 2010, at 12:22 pm, David Chelimsky wrote: > My inclination is to get this feature out with explicit non-support for 1.8.6, and then add support for 1.8.6 if we can get this to work. Working on that now - should be pushing some code (including Myron's contribution) later today. Do you have everything in place to finish this off? Happy to help out if you want me to do any more coding on this, but it sounds like you've figured out a solution. In which case I'll sit back and see how the changes fit with the shared examples I've got so far... Cheers Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran From dchelimsky at gmail.com Tue Aug 3 07:50:39 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 3 Aug 2010 06:50:39 -0500 Subject: [rspec-users] Evaluating shared example customisation block before shared block In-Reply-To: <3B1DB6C1-87E5-44F8-9E59-B23C66ED02C9@patchspace.co.uk> References: <30EC00AE-9668-48DC-9861-E234B7D87302@patchspace.co.uk> <09CFF5F4-E1F8-417E-9781-C264B44F8081@gmail.com> <92EF66E4-3748-462D-BC85-EEF0BF51C223@patchspace.co.uk> <2A82081A-ED3E-423B-A068-3FB067F8C4B6@gmail.com> <81E33C70-68CD-4415-BC9E-23D0F2B6F0FB@patchspace.co.uk> <621BAF47-4CEC-4364-B706-6DFF7C9155A1@gmail.com> <529E5DDF-1E2C-4F38-9DD4-DAD1350218FF@patchspace.co.uk> <4977696a-94a3-4467-9048-7c8845731a52@x18g2000pro.googlegroups.com> <9e1b1173-212e-4117-a2b0-fb79752bf9b5@p11g2000prf.googlegroups.com> <3B1DB6C1-87E5-44F8-9E59-B23C66ED02C9@patchspace.co.uk> Message-ID: <91BDC148-2F90-454E-A974-14FB4C2F0FA3@gmail.com> On Aug 3, 2010, at 6:43 AM, Ashley Moran wrote: > > On Aug 03, 2010, at 12:22 pm, David Chelimsky wrote: > >> My inclination is to get this feature out with explicit non-support for 1.8.6, and then add support for 1.8.6 if we can get this to work. Working on that now - should be pushing some code (including Myron's contribution) later today. > > Do you have everything in place to finish this off? Happy to help out if you want me to do any more coding on this, but it sounds like you've figured out a solution. In which case I'll sit back and see how the changes fit with the shared examples I've got so far... Pushed: http://github.com/rspec/rspec-core/commit/84303616be1ac2f8126675488947b47f6945cebe http://github.com/rspec/rspec-core/commit/3cea7b8bea51766d632e20bcc9ef15c64b719ea1 Please do let me know if this works with what you've got. The issue of the evaluation order is still up for grabs, but this now supports params to shared groups in Ruby >= 1.8.7. > > Cheers > Ash > > -- > http://www.patchspace.co.uk/ > http://www.linkedin.com/in/ashleymoran > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users From dchelimsky at gmail.com Tue Aug 3 10:03:32 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 3 Aug 2010 09:03:32 -0500 Subject: [rspec-users] [RSpec] Testing a helper with or without model layer? In-Reply-To: <826a4a227b246c16f7392878b335a257@ruby-forum.com> References: <826a4a227b246c16f7392878b335a257@ruby-forum.com> Message-ID: <45B428FC-640B-4936-8A2D-283DA14E5E94@gmail.com> On Aug 3, 2010, at 6:34 AM, Bruno Cardoso wrote: > Hi guys, > > I wanted to get a more experienced opinion about a test I had to do. > > I posted the code at pastie with comments for best visual readability: > > http://pastie.org/private/qvvrxubslvia2nv6l3km4q Even though the code is in a helper, it depends heavily on the model. This exhibits a code smell called Feature Envy, in which one object (the helper) does some computation but another object (the CfgInterface model) has all the data. Based on that, one might argue this method belongs on the model anyhow, in which case the argument of stubbing out the model layer makes little sense. There are also several expectations that overlap. It doesn't matter that the class is a Hash - what matters is that it behaves like a hash, which is demonstrated in other expectations. The fact that the keys exist is also demonstrated in the expectations that access those keys. Based on those comments, I'd probably do something like http://gist.github.com/506366. Then I'd figure out how to swap in factories for the fixtures - right now there's no way to understand what 'CONS_ALL_ACCOUNT' means without looking elsewhere. HTH, David > Any feedback is appreciated > > Thanks > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users From lists at ruby-forum.com Tue Aug 3 10:23:44 2010 From: lists at ruby-forum.com (Bruno Cardoso) Date: Tue, 3 Aug 2010 16:23:44 +0200 Subject: [rspec-users] [RSpec] Testing a helper with or without model layer? In-Reply-To: <45B428FC-640B-4936-8A2D-283DA14E5E94@gmail.com> References: <826a4a227b246c16f7392878b335a257@ruby-forum.com> <45B428FC-640B-4936-8A2D-283DA14E5E94@gmail.com> Message-ID: Hi David > Even though the code is in a helper, it depends heavily on the model. > This exhibits a code smell called Feature Envy, in which one object (the > helper) does some computation but another object (the CfgInterface > model) has all the data. Based on that, one might argue this method > belongs on the model anyhow, in which case the argument of stubbing out > the model layer makes little sense. I see your point and in this case you are probably right but what if my helper was more heavy on the processing and still very data dependent ? Should I use fixtures on the helper or should I stub/mock whatever I need to avoid the model layer within the helper ? > There are also several expectations that overlap. It doesn't matter that > the class is a Hash - what matters is that it behaves like a hash, which > is demonstrated in other expectations. The fact that the keys exist is > also demonstrated in the expectations that access those keys. Good point, thanks. > Based on those comments, I'd probably do something like > http://gist.github.com/506366. Then I'd figure out how to swap in > factories for the fixtures - right now there's no way to understand what > 'CONS_ALL_ACCOUNT' means without looking elsewhere. 'CONS_ALL_ACCOUNT' actually has no impact when using stub/mocks, 'CONS_ALL_ACCOUNT' was the input parameter the model was using to fetch data from the BD, in the second form of the test with stubs/mocks, this input parameter has no meaning since I'm controlling all return parameters. -- Posted via http://www.ruby-forum.com/. From kmandrup.github at gmail.com Tue Aug 3 16:06:10 2010 From: kmandrup.github at gmail.com (Kristian Mandrup) Date: Tue, 3 Aug 2010 13:06:10 -0700 (PDT) Subject: [rspec-users] RSpec 2 add-on for testing and specifying generators - initial release Message-ID: http://github.com/kristianmandrup/rspec_for_generators When creating Rails generators I noticed that the only option I could find for testing was to use a special Rails TestCase class created specifically for use with Test Unit. So I thought I could wrap it to be used with RSpec 2 instead. I now have a working first release with room for lots of improvements! But at least it seems to work fine for now, as demonstrated by a small RSpec 2 test suite that comes with it. Note: This library is NOT in any way an official RSpec 2 release of any sort. I only use the RSpec name to indicate that it is an add-on component for RSpec 2. That it can be used with RSpec 2. Not sure what other convention there would be to indicate this? Maybe I should rename it to something like the following to make it more clear? rspec2-addon-for-generators Hope you find it useful as a starting point. Free feel to patch it, refactor etc. Enjoy! Kristian From ashley.moran at patchspace.co.uk Tue Aug 3 17:35:55 2010 From: ashley.moran at patchspace.co.uk (Ashley Moran) Date: Tue, 3 Aug 2010 22:35:55 +0100 Subject: [rspec-users] Evaluating shared example customisation block before shared block In-Reply-To: <91BDC148-2F90-454E-A974-14FB4C2F0FA3@gmail.com> References: <30EC00AE-9668-48DC-9861-E234B7D87302@patchspace.co.uk> <09CFF5F4-E1F8-417E-9781-C264B44F8081@gmail.com> <92EF66E4-3748-462D-BC85-EEF0BF51C223@patchspace.co.uk> <2A82081A-ED3E-423B-A068-3FB067F8C4B6@gmail.com> <81E33C70-68CD-4415-BC9E-23D0F2B6F0FB@patchspace.co.uk> <621BAF47-4CEC-4364-B706-6DFF7C9155A1@gmail.com> <529E5DDF-1E2C-4F38-9DD4-DAD1350218FF@patchspace.co.uk> <4977696a-94a3-4467-9048-7c8845731a52@x18g2000pro.googlegroups.com> <9e1b1173-212e-4117-a2b0-fb79752bf9b5@p11g2000prf.googlegroups.com> <3B1DB6C1-87E5-44F8-9E59-B23C66ED02C9@patchspace.co.uk> <91BDC148-2F90-454E-A974-14FB4C2F0FA3@gmail.com> Message-ID: <19E5C86E-C5BF-4518-B132-9EAFA76E969D@patchspace.co.uk> On 3 Aug 2010, at 12:50 PM, David Chelimsky wrote: > Pushed: > > http://github.com/rspec/rspec-core/commit/84303616be1ac2f8126675488947b47f6945cebe > http://github.com/rspec/rspec-core/commit/3cea7b8bea51766d632e20bcc9ef15c64b719ea1 Awesomeness! > Please do let me know if this works with what you've got. In general, yes, this is a massive improvement! I've realised some things that never occurred to me before, though. Maybe you have some thoughts... I've put everything on a Gist[1] (which needs a few tweaks here and there, but I think it's a reasonably example). Notes: * DomainLib is my holding module for everything I've extracted out of the project source. Anything inside that is generic, analogous to eg ActiveRecord (eg Entity <-> AR::Base) * I've only pasted the specs, and only the contract-based ones at that (the implementation is not very interesting, nor is the interaction spec). * I don't like the word contract any more, at least not here. It needs a better name, probably something that would fit if you wrote a similar spec for ActiveRecord's has_many. Some things I ran into: First, I found that you can't use the block variables in local helper methods. Because Ruby methods aren't closures, I've had to replace methods like: def entity_dot_new_collection_member(*args) entity.send(:"new_#{item_name}", *args) end with: define_method :entity_dot_new_collection_member do |*args| entity.send(:"new_#{item_name}", *args) end Not a big deal, but it's not as readable as it was before. (Not that it was exactly large-print Winnie the Pooh to start with, given the abstract nature of the shared examples.) Second, you can't refer to `described_class` in the descriptions. I don't know why I though you'd be able to, but it would be nice if it worked :) (You can see the place where my failed attempt was, where I left .) Finally, I realised something when I added another example. I should say though, that all this time, I was only using the shared examples with one collection on the entity, and I added another a few minutes ago just for fun, and it just worked... I like :) But it raised a point about things that are common to all shared examples, and parameters to individual uses. In my example case, `entity_class` and `entity` are relevant to both of the "collection" shared example groups, but `collection_name`, `item_name`, `class_name` are parameters to the shared examples individually. With the current setup, there's no way to require that a host group provides eg `entity_class`. And also, if it's defined as a `let` in the host, you can't use it in the descriptions in the shared example group (which you couldn't before, of course). So I think this solves 90% of the problems I had before, and is certainly a workable solution to the specs I'm trying to write. I'd love to hear your thoughts on the rest though. > The issue of the evaluation order is still up for grabs, but this now supports params to shared groups in Ruby >= 1.8.7. Well, I deliberately didn't check what order you ended up using! Whatever it is works for me now, although I guess future experiments could change that... Cheers! Ash [1] http://gist.github.com/507140 -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran From dchelimsky at gmail.com Tue Aug 3 20:05:02 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 3 Aug 2010 19:05:02 -0500 Subject: [rspec-users] Evaluating shared example customisation block before shared block In-Reply-To: <19E5C86E-C5BF-4518-B132-9EAFA76E969D@patchspace.co.uk> References: <30EC00AE-9668-48DC-9861-E234B7D87302@patchspace.co.uk> <09CFF5F4-E1F8-417E-9781-C264B44F8081@gmail.com> <92EF66E4-3748-462D-BC85-EEF0BF51C223@patchspace.co.uk> <2A82081A-ED3E-423B-A068-3FB067F8C4B6@gmail.com> <81E33C70-68CD-4415-BC9E-23D0F2B6F0FB@patchspace.co.uk> <621BAF47-4CEC-4364-B706-6DFF7C9155A1@gmail.com> <529E5DDF-1E2C-4F38-9DD4-DAD1350218FF@patchspace.co.uk> <4977696a-94a3-4467-9048-7c8845731a52@x18g2000pro.googlegroups.com> <9e1b1173-212e-4117-a2b0-fb79752bf9b5@p11g2000prf.googlegroups.com> <3B1DB6C1-87E5-44F8-9E59-B23C66ED02C9@patchspace.co.uk> <91BDC148-2F90-454E-A974-14FB4C2F0FA3@gmail.com> <19E5C86E-C5BF-4518-B132-9EAFA76E969D@patchspace.co.uk> Message-ID: <6A7708A9-FE6D-452B-8002-BB618CF14243@gmail.com> On Aug 3, 2010, at 4:35 PM, Ashley Moran wrote: > > On 3 Aug 2010, at 12:50 PM, David Chelimsky wrote: > >> Pushed: >> >> http://github.com/rspec/rspec-core/commit/84303616be1ac2f8126675488947b47f6945cebe >> http://github.com/rspec/rspec-core/commit/3cea7b8bea51766d632e20bcc9ef15c64b719ea1 > > Awesomeness! > > >> Please do let me know if this works with what you've got. > > In general, yes, this is a massive improvement! I've realised some things that never occurred to me before, though. Maybe you have some thoughts... > > I've put everything on a Gist[1] (which needs a few tweaks here and there, but I think it's a reasonably example). Notes: > > * DomainLib is my holding module for everything I've extracted out of the project source. Anything inside that is generic, analogous to eg ActiveRecord (eg Entity <-> AR::Base) > > * I've only pasted the specs, and only the contract-based ones at that (the implementation is not very interesting, nor is the interaction spec). > > * I don't like the word contract any more, at least not here. It needs a better name, probably something that would fit if you wrote a similar spec for ActiveRecord's has_many. I actually like contract a lot. Maybe we'll need alias_shared_examples_for_to :) > Some things I ran into: > > First, I found that you can't use the block variables in local helper methods. Because Ruby methods aren't closures, I've had to replace methods like: > > def entity_dot_new_collection_member(*args) > entity.send(:"new_#{item_name}", *args) > end > > with: > > define_method :entity_dot_new_collection_member do |*args| > entity.send(:"new_#{item_name}", *args) > end > > Not a big deal, but it's not as readable as it was before. (Not that it was exactly large-print Winnie the Pooh to start with, given the abstract nature of the shared examples.) This is just Ruby. It bugged me for a while too, but mostly because I kept forgetting. Now I'm completely accustomed to it and def and define_method seem quite the same to me. > Second, you can't refer to `described_class` in the descriptions. I don't know why I though you'd be able to, but it would be nice if it worked :) (You can see the place where my failed attempt was, where I left .) This was a mis-alignment between names in the group and its examples (example_group.describes == example.described_class), but is now fixed (you can refer to described_class in both cases): http://github.com/rspec/rspec-core/commit/b236a8d8927da108097fed7982d1450e4701939d > Finally, I realised something when I added another example. I should say though, that all this time, I was only using the shared examples with one collection on the entity, and I added another a few minutes ago just for fun, and it just worked... I like :) But it raised a point about things that are common to all shared examples, and parameters to individual uses. In my example case, `entity_class` and `entity` are relevant to both of the "collection" shared example groups, but `collection_name`, `item_name`, `class_name` are parameters to the shared examples individually. > > With the current setup, there's no way to require that a host group provides eg `entity_class`. shared_examples_for "foo" do raise "gotta define entity_class" unless public_instance_methods.map{|m|m.to_s).include?("entity_class") end > And also, if it's defined as a `let` in the host, you can't use it in the descriptions in the shared example group (which you couldn't before, of course). Right - the only thing available to descriptions is going to be the params you pass in. > So I think this solves 90% of the problems I had before, and is certainly a workable solution to the specs I'm trying to write. I'd love to hear your thoughts on the rest though. > > >> The issue of the evaluation order is still up for grabs, but this now supports params to shared groups in Ruby >= 1.8.7. > > Well, I deliberately didn't check what order you ended up using! Whatever it is works for me now, although I guess future experiments could change that... Thanks for all the feedback! Cheers, David > > > Cheers! > Ash > > > [1] http://gist.github.com/507140 > > > -- > http://www.patchspace.co.uk/ > http://www.linkedin.com/in/ashleymoran > > > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users From dchelimsky at gmail.com Tue Aug 3 23:22:22 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 3 Aug 2010 22:22:22 -0500 Subject: [rspec-users] RSpec 2 add-on for testing and specifying generators - initial release In-Reply-To: References: Message-ID: <1059B733-7977-4447-828E-C41AE19162BA@gmail.com> On Aug 3, 2010, at 3:06 PM, Kristian Mandrup wrote: > http://github.com/kristianmandrup/rspec_for_generators > > When creating Rails generators I noticed that the only option I could > find for testing was to use a special Rails TestCase class created > specifically for use with Test Unit. > So I thought I could wrap it to be used with RSpec 2 instead. I now > have a working first release with room for lots of improvements! But > at least it seems to work fine for now, as demonstrated by a small > RSpec 2 test suite that comes with it. > > Note: This library is NOT in any way an official RSpec 2 release of > any sort. I only use the RSpec name to indicate that it is an add-on > component for RSpec 2. That it can be used with RSpec 2. > Not sure what other convention there would be to indicate this? > > Maybe I should rename it to something like the following to make it > more clear? > > rspec2-addon-for-generators Ben Mabey called his email-spec. So maybe generator-spec? > > Hope you find it useful as a starting point. Free feel to patch it, > refactor etc. > Enjoy! > > Kristian > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users From dchelimsky at gmail.com Tue Aug 3 23:24:41 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 3 Aug 2010 22:24:41 -0500 Subject: [rspec-users] [RSpec] Testing a helper with or without model layer? In-Reply-To: References: <826a4a227b246c16f7392878b335a257@ruby-forum.com> <45B428FC-640B-4936-8A2D-283DA14E5E94@gmail.com> Message-ID: On Aug 3, 2010, at 9:23 AM, Bruno Cardoso wrote: > Hi David > >> Even though the code is in a helper, it depends heavily on the model. >> This exhibits a code smell called Feature Envy, in which one object (the >> helper) does some computation but another object (the CfgInterface >> model) has all the data. Based on that, one might argue this method >> belongs on the model anyhow, in which case the argument of stubbing out >> the model layer makes little sense. > > I see your point and in this case you are probably right but what if my > helper was more heavy on the processing and still very data dependent ? > Should I use fixtures on the helper or should I stub/mock whatever I > need to avoid the model layer within the helper ? It really depends on how deep the helper is reaching into the model. Ideally, when you're stubbing a layer, you want to be able to stub one thing. In this example, there are many things that need to be stubbed. A common example is a display formatter for a person's name: it "concats the first and last name" do person = double('person', :first_name => "Joe", :last_name => "Smith") helper.full_name_for(person).should == "Joe Smith" end Here we're just stubbing a couple of values on one object - simple. In this case it makes sense to just stub the model. > >> There are also several expectations that overlap. It doesn't matter that >> the class is a Hash - what matters is that it behaves like a hash, which >> is demonstrated in other expectations. The fact that the keys exist is >> also demonstrated in the expectations that access those keys. > > Good point, thanks. > >> Based on those comments, I'd probably do something like >> http://gist.github.com/506366. Then I'd figure out how to swap in >> factories for the fixtures - right now there's no way to understand what >> 'CONS_ALL_ACCOUNT' means without looking elsewhere. > > 'CONS_ALL_ACCOUNT' actually has no impact when using stub/mocks, > 'CONS_ALL_ACCOUNT' was the input parameter the model was using to fetch > data from the BD, in the second form of the test with stubs/mocks, this > input parameter has no meaning since I'm controlling all return > parameters. From myron.marston at gmail.com Wed Aug 4 02:55:46 2010 From: myron.marston at gmail.com (Myron Marston) Date: Tue, 3 Aug 2010 23:55:46 -0700 (PDT) Subject: [rspec-users] Evaluating shared example customisation block before shared block In-Reply-To: <6A7708A9-FE6D-452B-8002-BB618CF14243@gmail.com> References: <30EC00AE-9668-48DC-9861-E234B7D87302@patchspace.co.uk> <621BAF47-4CEC-4364-B706-6DFF7C9155A1@gmail.com> <529E5DDF-1E2C-4F38-9DD4-DAD1350218FF@patchspace.co.uk> <4977696a-94a3-4467-9048-7c8845731a52@x18g2000pro.googlegroups.com> <9e1b1173-212e-4117-a2b0-fb79752bf9b5@p11g2000prf.googlegroups.com> <3B1DB6C1-87E5-44F8-9E59-B23C66ED02C9@patchspace.co.uk> <91BDC148-2F90-454E-A974-14FB4C2F0FA3@gmail.com> <19E5C86E-C5BF-4518-B132-9EAFA76E969D@patchspace.co.uk> <6A7708A9-FE6D-452B-8002-BB618CF14243@gmail.com> Message-ID: <2115c570-1382-46c4-98bc-66e9fb393ff6@s24g2000pri.googlegroups.com> Ashley: thanks for posting the example. It's nice to see how this all fits together. Re: RSpec 2 for ruby 1.8.6: I don't see RSpec 2 as being all that useful for Rails 2.x projects on ruby 1.8.6. However, it's still very important for gems. I just converted one of my projects (VCR[1]) to RSpec 2, and VCR supports ruby 1.8.6, 1.8.7 and 1.9.1. If we remove ruby 1.8.6 support from RSpec 2, I'd have to migrate back to RSpec 1.x so that I can continue to run the spec suite on 1.8.6. I imagine there will be plenty of other libraries that will want to upgrade to using RSpec 2 after the final release, while still supporting 1.8.6. Good news: I messed around with module_exec some more, and I think I have a working implementation for 1.8.6[2]. This was complicated enough that I wanted to work on it in isolation from RSpec; hence the separate github project. We'll probably want to re-organize it a bit before merging it in, if it's deemed "good enough" to work for our needs. It has some specs that pass for module_exec on 1.8.7, and they pass on 1.8.6 with my implementation, too. There may be cases where it still doesn't work quite right, though--feel free to fork, add specs, etc. Myron [1] http://github.com/myronmarston/vcr [2] http://github.com/myronmarston/module_exec From ashley.moran at patchspace.co.uk Wed Aug 4 04:22:47 2010 From: ashley.moran at patchspace.co.uk (Ashley Moran) Date: Wed, 4 Aug 2010 09:22:47 +0100 Subject: [rspec-users] Evaluating shared example customisation block before shared block In-Reply-To: <6A7708A9-FE6D-452B-8002-BB618CF14243@gmail.com> References: <30EC00AE-9668-48DC-9861-E234B7D87302@patchspace.co.uk> <09CFF5F4-E1F8-417E-9781-C264B44F8081@gmail.com> <92EF66E4-3748-462D-BC85-EEF0BF51C223@patchspace.co.uk> <2A82081A-ED3E-423B-A068-3FB067F8C4B6@gmail.com> <81E33C70-68CD-4415-BC9E-23D0F2B6F0FB@patchspace.co.uk> <621BAF47-4CEC-4364-B706-6DFF7C9155A1@gmail.com> <529E5DDF-1E2C-4F38-9DD4-DAD1350218FF@patchspace.co.uk> <4977696a-94a3-4467-9048-7c8845731a52@x18g2000pro.googlegroups.com> <9e1b1173-212e-4117-a2b0-fb79752bf9b5@p11g2000prf.googlegroups.com> <3B1DB6C1-87E5-44F8-9E59-B23C66ED02C9@patchspace.co.uk> <91BDC148-2F90-454E-A974-14FB4C2F0FA3@gmail.com> <19E5C86E-C5BF-4518-B132-9EAFA76E969D@patchspace.co.uk> <6A7708A9-FE6D-452B-8002-BB618CF14243@gmail.com> Message-ID: <8C613166-4BD8-4B6B-915B-F87252CE6E95@patchspace.co.uk> On 4 Aug 2010, at 1:05 AM, David Chelimsky wrote: > I actually like contract a lot. Maybe we'll need alias_shared_examples_for_to :) Haha, actually that gets +1 from me! Should I file a ticket? :) In general I like contract, I just wasn't sure it was the right word for this usage of shared examples. Maybe I just need to reword the shared examples, to write something like this: it_satisfies_contract "container of", :children, :child, Child.name (Obviously, if I had an inflection library in place, you could drop the last 2 args) > This is just Ruby. It bugged me for a while too, but mostly because I kept forgetting. Now I'm completely accustomed to it and def and define_method seem quite the same to me. Maybe. Perhaps then Ruby needs a neater closure-based method syntax eg: foo = 1 defc my_method(bar) foo + bar end or some such... > This was a mis-alignment between names in the group and its examples (example_group.describes == example.described_class), but is now fixed (you can refer to described_class in both cases):http://github.com/rspec/rspec-core/commit/b236a8d8927da108097fed7982d1450e4701939d Works for me! Ta :) > shared_examples_for "foo" do > raise "gotta define entity_class" unless public_instance_methods.map{|m|m.to_s).include?("entity_class") > end Aye, I guess I'm just in love with DSLs... If I feel the need I might write a simple DSL and see if it's worth it. >> And also, if it's defined as a `let` in the host, you can't use it in the descriptions in the shared example group (which you couldn't before, of course). > > Right - the only thing available to descriptions is going to be the params you pass in. I have a feeling this will cause a misalignment, but maybe not. I'll work through some more practical examples and see how it plays out. BTW any idea when the next beta will go out, so that this is in a released gem? I've got it working, but I had no luck using Bundler's :path option so I ended up having to build and install the gems into my project gemset. That's probably just a RubyGems/Bundler issue though. Cheers Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran From ashley.moran at patchspace.co.uk Wed Aug 4 04:30:41 2010 From: ashley.moran at patchspace.co.uk (Ashley Moran) Date: Wed, 4 Aug 2010 09:30:41 +0100 Subject: [rspec-users] Evaluating shared example customisation block before shared block In-Reply-To: <2115c570-1382-46c4-98bc-66e9fb393ff6@s24g2000pri.googlegroups.com> References: <30EC00AE-9668-48DC-9861-E234B7D87302@patchspace.co.uk> <621BAF47-4CEC-4364-B706-6DFF7C9155A1@gmail.com> <529E5DDF-1E2C-4F38-9DD4-DAD1350218FF@patchspace.co.uk> <4977696a-94a3-4467-9048-7c8845731a52@x18g2000pro.googlegroups.com> <9e1b1173-212e-4117-a2b0-fb79752bf9b5@p11g2000prf.googlegroups.com> <3B1DB6C1-87E5-44F8-9E59-B23C66ED02C9@patchspace.co.uk> <91BDC148-2F90-454E-A974-14FB4C2F0FA3@gmail.com> <19E5C86E-C5BF-4518-B132-9EAFA76E969D@patchspace.co.uk> <6A7708A9-FE6D-452B-8002-BB618CF14243@gmail.com> <2115c570-1382-46c4-98bc-66e9fb393ff6@s24g2000pri.googlegroups.com> Message-ID: <00FFDC51-1CCC-49C2-966F-86B14D935E94@patchspace.co.uk> On 4 Aug 2010, at 7:55 AM, Myron Marston wrote: > Ashley: thanks for posting the example. It's nice to see how this all > fits together. Arguably it would have made more sense to post that example *before*, rather than expecting you all to read my mind :) I'm pleased with how it's working out so far. I need to write a lot more of these to know though. I only got as far as this one example before deciding to shave the shared example yak before moving on. > Re: RSpec 2 for ruby 1.8.6: I don't see RSpec 2 as being all that > useful for Rails 2.x projects on ruby 1.8.6. However, it's still very > important for gems. I just converted one of my projects (VCR[1]) to > RSpec 2, and VCR supports ruby 1.8.6, 1.8.7 and 1.9.1. If we remove > ruby 1.8.6 support from RSpec 2, I'd have to migrate back to RSpec 1.x > so that I can continue to run the spec suite on 1.8.6. I imagine > there will be plenty of other libraries that will want to upgrade to > using RSpec 2 after the final release, while still supporting 1.8.6. Cool, if it's possible to maintain 1.8.6 support in RSpec 2 then by all means do so. I wasn't aware that such a large amount of code needed to run on 1.8.6, I assumed most had moved to 1.8.7. Doesn't look like it takes too much to monkeypatch 1.8.6 up to spec anyway. Cheers Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran From ashley.moran at patchspace.co.uk Wed Aug 4 04:43:24 2010 From: ashley.moran at patchspace.co.uk (Ashley Moran) Date: Wed, 4 Aug 2010 09:43:24 +0100 Subject: [rspec-users] Evaluating shared example customisation block before shared block In-Reply-To: <6A7708A9-FE6D-452B-8002-BB618CF14243@gmail.com> References: <30EC00AE-9668-48DC-9861-E234B7D87302@patchspace.co.uk> <09CFF5F4-E1F8-417E-9781-C264B44F8081@gmail.com> <92EF66E4-3748-462D-BC85-EEF0BF51C223@patchspace.co.uk> <2A82081A-ED3E-423B-A068-3FB067F8C4B6@gmail.com> <81E33C70-68CD-4415-BC9E-23D0F2B6F0FB@patchspace.co.uk> <621BAF47-4CEC-4364-B706-6DFF7C9155A1@gmail.com> <529E5DDF-1E2C-4F38-9DD4-DAD1350218FF@patchspace.co.uk> <4977696a-94a3-4467-9048-7c8845731a52@x18g2000pro.googlegroups.com> <9e1b1173-212e-4117-a2b0-fb79752bf9b5@p11g2000prf.googlegroups.com> <3B1DB6C1-87E5-44F8-9E59-B23C66ED02C9@patchspace.co.uk> <91BDC148-2F90-454E-A974-14FB4C2F0FA3@gmail.com> <19E5C86E-C5BF-4518-B132-9EAFA76E969D@patchspace.co.uk> <6A7708A9-FE6D-452B-8002-BB618CF14243@gmail.com> Message-ID: <417477F5-605B-46C7-B37F-E20DD4BA163E@patchspace.co.uk> On 4 Aug 2010, at 1:05 AM, David Chelimsky wrote: > One other thought I've had is keyword syntax. While currently I'm writing: it_satisfies_contract "[Entity] Collection:", :children, :child, Child.name I prefer keyword arguments, so I'd like to write: it_satisfies_contract "[Entity] Collection:", :children, item_name: "child", class_name: Child.name Currently that would mean rewriting the contract like this: contract "[Entity] Collection:" do |collection_name, options| # ... describe "#{collection_name}" do describe "Helper methods:" do describe "#new_#{options[:item_name]}, #get_#{options[:item_name]}" do # ... WDYT about RSpec automatically translating keyword options to methods? They'd need to be defined as singleton class methods and instance methods to have the same availability as block parameters. Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran From kmandrup.github at gmail.com Wed Aug 4 06:22:14 2010 From: kmandrup.github at gmail.com (Kristian Mandrup) Date: Wed, 4 Aug 2010 03:22:14 -0700 (PDT) Subject: [rspec-users] RSpec 2 add-on for testing and specifying generators - initial release In-Reply-To: <1059B733-7977-4447-828E-C41AE19162BA@gmail.com> References: <1059B733-7977-4447-828E-C41AE19162BA@gmail.com> Message-ID: <03d89a11-3294-4039-ae6c-db8caf384499@t2g2000yqe.googlegroups.com> Alright, I will rename it when I get to it. Just improved it in a major fashion! Now as simple as this to set it up :) # spec/spec_helper.rb require 'rspec' require 'rspec_for_generators' Rails.application.configure do # use default rails tmp dir config.root_dir = TmpRails.root_dir(__FILE__) end # configure it! RSpec::Generator.configure! And to use it in a spec: require File.expand_path(File.dirname(__FILE__) + '/../spec_helper') require_generator :demo describe 'model_generator' do include RSpec::Rails::Orm::ActiveRecord before :each do RSpec::Generator.setup_generator 'model_generator' do tests DemoGenerator end remove_model 'account' end after :each do remove_model 'account' end it "should decorate an existing Account model file with include Demo" do RSpec::Generator.with_generator do |g| name = 'account' create_model name g.run_generator %w{account} g.should generate_file name, :model do |content| content.should have_class name do |klass| klass.should include_module 'Demo' end end end end end On Aug 4, 5:22?am, David Chelimsky wrote: > On Aug 3, 2010, at 3:06 PM, Kristian Mandrup wrote: > > > > >http://github.com/kristianmandrup/rspec_for_generators > > > When creating Rails generators I noticed that the only option I could > > find for testing was to use a special Rails TestCase class created > > specifically for use with Test Unit. > > So I thought I could wrap it to be used with RSpec 2 instead. I now > > have a working first release with room for lots of improvements! ?But > > at least it seems to work fine for now, as demonstrated by a small > > RSpec 2 test suite that comes with it. > > > Note: This library is NOT in any way an official RSpec 2 release of > > any sort. I only use the RSpec name to indicate that it is an add-on > > component for RSpec 2. That it can be used with RSpec 2. > > Not sure what other convention there would be to indicate this? > > > Maybe I should rename it to something like the following to make it > > more clear? > > > rspec2-addon-for-generators > > Ben Mabey called his email-spec. So maybe generator-spec? > > > > > Hope you find it useful as a starting point. Free feel to patch it, > > refactor etc. > > Enjoy! > > > Kristian > > _______________________________________________ > > rspec-users mailing list > > rspec-us... at rubyforge.org > >http://rubyforge.org/mailman/listinfo/rspec-users > > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users From kmandrup.github at gmail.com Wed Aug 4 06:32:29 2010 From: kmandrup.github at gmail.com (Kristian Mandrup) Date: Wed, 4 Aug 2010 03:32:29 -0700 (PDT) Subject: [rspec-users] RSpec 2 add-on for testing and specifying generators - initial release In-Reply-To: <1059B733-7977-4447-828E-C41AE19162BA@gmail.com> References: <1059B733-7977-4447-828E-C41AE19162BA@gmail.com> Message-ID: <87d6dc4b-69e5-4135-85e6-c79865fd1631@d8g2000yqf.googlegroups.com> Even simpler config now :) require 'rspec' require 'rspec_for_generators' # configure it like this to use default settings RSpec::Generator.configure_root_dir(__FILE__) From dchelimsky at gmail.com Wed Aug 4 07:41:03 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 4 Aug 2010 06:41:03 -0500 Subject: [rspec-users] Evaluating shared example customisation block before shared block In-Reply-To: <417477F5-605B-46C7-B37F-E20DD4BA163E@patchspace.co.uk> References: <30EC00AE-9668-48DC-9861-E234B7D87302@patchspace.co.uk> <09CFF5F4-E1F8-417E-9781-C264B44F8081@gmail.com> <92EF66E4-3748-462D-BC85-EEF0BF51C223@patchspace.co.uk> <2A82081A-ED3E-423B-A068-3FB067F8C4B6@gmail.com> <81E33C70-68CD-4415-BC9E-23D0F2B6F0FB@patchspace.co.uk> <621BAF47-4CEC-4364-B706-6DFF7C9155A1@gmail.com> <529E5DDF-1E2C-4F38-9DD4-DAD1350218FF@patchspace.co.uk> <4977696a-94a3-4467-9048-7c8845731a52@x18g2000pro.googlegroups.com> <9e1b1173-212e-4117-a2b0-fb79752bf9b5@p11g2000prf.googlegroups.com> <3B1DB6C1-87E5-44F8-9E59-B23C66ED02C9@patchspace.co.uk> <91BDC148-2F90-454E-A974-14FB4C2F0FA3@gmail.com> <19E5C86E-C5BF-4518-B132-9EAFA76E969D@patchspace.co.uk> <6A7708A9-FE6D-452B-8002-BB618CF14243@gmail.com> <417477F5-605B-46C7-B37F-E20DD4BA163E@patchspace.co.uk> Message-ID: On Aug 4, 2010, at 3:43 AM, Ashley Moran wrote: > > On 4 Aug 2010, at 1:05 AM, David Chelimsky wrote: > >> > > > One other thought I've had is keyword syntax. While currently I'm writing: > > it_satisfies_contract "[Entity] Collection:", :children, :child, Child.name > > I prefer keyword arguments, so I'd like to write: > > it_satisfies_contract "[Entity] Collection:", > :children, > item_name: "child", > class_name: Child.name > > Currently that would mean rewriting the contract like this: > > contract "[Entity] Collection:" do |collection_name, options| > > # ... > > describe "#{collection_name}" do > describe "Helper methods:" do > describe "#new_#{options[:item_name]}, #get_#{options[:item_name]}" do > > # ... > > WDYT about RSpec automatically translating keyword options to methods? What happens if the shared spec author really wants it to just be a hash? Do you think that's a valid use case? > They'd need to be defined as singleton class methods and instance methods to have the same availability as block parameters. > > Ash > > -- > http://www.patchspace.co.uk/ > http://www.linkedin.com/in/ashleymoran > > > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users From dchelimsky at gmail.com Wed Aug 4 07:44:51 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 4 Aug 2010 06:44:51 -0500 Subject: [rspec-users] Evaluating shared example customisation block before shared block In-Reply-To: <2115c570-1382-46c4-98bc-66e9fb393ff6@s24g2000pri.googlegroups.com> References: <30EC00AE-9668-48DC-9861-E234B7D87302@patchspace.co.uk> <621BAF47-4CEC-4364-B706-6DFF7C9155A1@gmail.com> <529E5DDF-1E2C-4F38-9DD4-DAD1350218FF@patchspace.co.uk> <4977696a-94a3-4467-9048-7c8845731a52@x18g2000pro.googlegroups.com> <9e1b1173-212e-4117-a2b0-fb79752bf9b5@p11g2000prf.googlegroups.com> <3B1DB6C1-87E5-44F8-9E59-B23C66ED02C9@patchspace.co.uk> <91BDC148-2F90-454E-A974-14FB4C2F0FA3@gmail.com> <19E5C86E-C5BF-4518-B132-9EAFA76E969D@patchspace.co.uk> <6A7708A9-FE6D-452B-8002-BB618CF14243@gmail.com> <2115c570-1382-46c4-98bc-66e9fb393ff6@s24g2000pri.googlegroups.com> Message-ID: <1436A904-8C11-4EB1-A056-6F52B7D7864D@gmail.com> On Aug 4, 2010, at 1:55 AM, Myron Marston wrote: > Ashley: thanks for posting the example. It's nice to see how this all > fits together. > > Re: RSpec 2 for ruby 1.8.6: I don't see RSpec 2 as being all that > useful for Rails 2.x projects on ruby 1.8.6. However, it's still very > important for gems. I just converted one of my projects (VCR[1]) to > RSpec 2, and VCR supports ruby 1.8.6, 1.8.7 and 1.9.1. If we remove > ruby 1.8.6 support from RSpec 2, I'd have to migrate back to RSpec 1.x > so that I can continue to run the spec suite on 1.8.6. I imagine > there will be plenty of other libraries that will want to upgrade to > using RSpec 2 after the final release, while still supporting 1.8.6. > > Good news: I messed around with module_exec some more, and I think I > have a working implementation for 1.8.6[2]. This was complicated > enough that I wanted to work on it in isolation from RSpec; hence the > separate github project. We'll probably want to re-organize it a bit > before merging it in, if it's deemed "good enough" to work for our > needs. It has some specs that pass for module_exec on 1.8.7, and they > pass on 1.8.6 with my implementation, too. There may be cases where > it still doesn't work quite right, though--feel free to fork, add > specs, etc. Hey Myron - I think what you have is perfectly fine. The only issue I ran into was that of defining instance methods, and your solution seems sound. I wouldn't even bother to undef those methods. We're not putting module_exec in as an API. In fact, in rspec, I think we should change the names of module_exec and instance_exec to something rspec-specific so that users don't rely on our implementation for other purposes. Something like: def module_eval_with_args(*args, &block) if respond_to?(:module_exec) module_exec(*args, &block) else # custom solution end end At that point, as long as all the shared group specs are passing, we're good. Make sense? > > Myron > > [1] http://github.com/myronmarston/vcr > [2] http://github.com/myronmarston/module_exec > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users From lists at ruby-forum.com Wed Aug 4 12:35:36 2010 From: lists at ruby-forum.com (Bruno Cardoso) Date: Wed, 4 Aug 2010 18:35:36 +0200 Subject: [rspec-users] [RSpec] Testing a helper with or without model layer? In-Reply-To: References: <826a4a227b246c16f7392878b335a257@ruby-forum.com> <45B428FC-640B-4936-8A2D-283DA14E5E94@gmail.com> Message-ID: <27a509d6c8b758d9f13efbc25a589b16@ruby-forum.com> David Chelimsky wrote: > It really depends on how deep the helper is reaching into the model. > Ideally, when you're stubbing a layer, you want to be able to stub one > thing. In this example, there are many things that need to be stubbed. A > common example is a display formatter for a person's name: > > it "concats the first and last name" do > person = double('person', :first_name => "Joe", :last_name => "Smith") > helper.full_name_for(person).should == "Joe Smith" > end > > Here we're just stubbing a couple of values on one object - simple. In > this case it makes sense to just stub the model. Thanks again David. -- Posted via http://www.ruby-forum.com/. From lists at ruby-forum.com Wed Aug 4 12:41:58 2010 From: lists at ruby-forum.com (Bruno Cardoso) Date: Wed, 4 Aug 2010 18:41:58 +0200 Subject: [rspec-users] [RSpec] Dynamic reloading with Object.send(:remove_const) Message-ID: Hi, I have a function that adds dynamic validations to my models. I use a combination of ":remove_const" and "load" methods to reload the code everytime I want to re-apply my dynamic validations. It seams RSpec has some issues with this. I posted here a simpler example code that shows what I mean: http://pastie.org/private/ruvgxgipxfge6yzuudbq Is it possible to test this with RSpec? Regards -- Posted via http://www.ruby-forum.com/. From lille.penguini at gmail.com Wed Aug 4 13:44:34 2010 From: lille.penguini at gmail.com (Lille) Date: Wed, 4 Aug 2010 10:44:34 -0700 (PDT) Subject: [rspec-users] [newbie] tradeoffs of direct model access vs. simulated browser (webrat) Message-ID: <07fb7a0f-b852-4929-8128-343419aa6fc2@k19g2000yqc.googlegroups.com> Hi, My app involves the elicitation of tabular data over a succession of controller/model/view groups. The net result is a numeric outcome based on the entered data (basically, it's a spreadsheet on Rails.) Here is the nub of my question about developing such a thing with RSpec: + if I test with a simulated browser approach, my scenarios will need span multiple controller/model/view triads to confirm the expected result in as many cases as I feel I need to cover. Basically, an entire app use-cycle is contained in every scenario -- this doesn't remind me of anything I've seen in "The RSpec Book", for example. + I think I prefer rspec'ing the models directly -- it's concise and I don't duplicate simulated browser actions for no particular reason. What's the point of confirming that different data in the same set of fields is submitted successfully, like 20 times? I'll only simulate the browser to build the view/controllers and test their behavior when inputs are inadequate or require differential responses. My preferred strategy is sort of like saying to the client: 1) here are all the numeric outcomes we need to confirm, and 2) here in a smaller, overlapping set are the behavioral outcomes we need to confirm In short, it seems to me the simulated browser approach (webrat) is overkill when one is dealing with exhaustive cases and there is no differential response in the controller or view parts based on them. Lille From myron.marston at gmail.com Wed Aug 4 14:35:43 2010 From: myron.marston at gmail.com (Myron Marston) Date: Wed, 4 Aug 2010 11:35:43 -0700 (PDT) Subject: [rspec-users] Evaluating shared example customisation block before shared block In-Reply-To: <1436A904-8C11-4EB1-A056-6F52B7D7864D@gmail.com> References: <30EC00AE-9668-48DC-9861-E234B7D87302@patchspace.co.uk> <4977696a-94a3-4467-9048-7c8845731a52@x18g2000pro.googlegroups.com> <9e1b1173-212e-4117-a2b0-fb79752bf9b5@p11g2000prf.googlegroups.com> <3B1DB6C1-87E5-44F8-9E59-B23C66ED02C9@patchspace.co.uk> <91BDC148-2F90-454E-A974-14FB4C2F0FA3@gmail.com> <19E5C86E-C5BF-4518-B132-9EAFA76E969D@patchspace.co.uk> <6A7708A9-FE6D-452B-8002-BB618CF14243@gmail.com> <2115c570-1382-46c4-98bc-66e9fb393ff6@s24g2000pri.googlegroups.com> <1436A904-8C11-4EB1-A056-6F52B7D7864D@gmail.com> Message-ID: > I wouldn't even bother to undef those methods. If we don't undef the methods, then the semantics of the #module_eval_with_args (or whatever we call it) will be different on 1.8.6 and other versions. On 1.8.6, a method definition in the block would define both an instance method _and_ a class method. Someone could write a spec against 1.8.6, and accidentally call the class method, not realizing they've done this, and the spec wouldn't work on 1.8.7 and above since the class method won't be there. So I think the undefs are important, and I don't think it adds too much complexity. > Something like: > > def module_eval_with_args(*args, &block) > ? if respond_to?(:module_exec) > ? ? module_exec(*args, &block) > ? else > ? ? # custom solution > ? end > end > > At that point, as long as all the shared group specs are passing, we're good. Make sense? Makes total sense. I'll work on porting this to RSpec, and open an github issue with a link to the commits when I'm done. Thanks! From matt at mattwynne.net Wed Aug 4 14:58:53 2010 From: matt at mattwynne.net (Matt Wynne) Date: Wed, 4 Aug 2010 19:58:53 +0100 Subject: [rspec-users] [newbie] tradeoffs of direct model access vs. simulated browser (webrat) In-Reply-To: <07fb7a0f-b852-4929-8128-343419aa6fc2@k19g2000yqc.googlegroups.com> References: <07fb7a0f-b852-4929-8128-343419aa6fc2@k19g2000yqc.googlegroups.com> Message-ID: <6C73ECDD-8FD9-40D9-BB80-967BA9BE9CEF@mattwynne.net> On 4 Aug 2010, at 18:44, Lille wrote: > Hi, > > My app involves the elicitation of tabular data over a succession of > controller/model/view groups. The net result is a numeric outcome > based on the entered data (basically, it's a spreadsheet on Rails.) > > Here is the nub of my question about developing such a thing with > RSpec: > > + if I test with a simulated browser approach, my scenarios will need > span multiple controller/model/view triads to confirm the expected > result in as many cases as I feel I need to cover. Basically, an > entire app use-cycle is contained in every scenario -- this doesn't > remind me of anything I've seen in "The RSpec Book", for example. > > + I think I prefer rspec'ing the models directly -- it's concise and I > don't duplicate simulated browser actions for no particular reason. > What's the point of confirming that different data in the same set of > fields is submitted successfully, like 20 times? I'll only simulate > the browser to build the view/controllers and test their behavior when > inputs are inadequate or require differential responses. > > My preferred strategy is sort of like saying to the client: 1) here > are all the numeric outcomes we need to confirm, and 2) here in a > smaller, overlapping set are the behavioral outcomes we need to > confirm > > In short, it seems to me the simulated browser approach (webrat) is > overkill when one is dealing with exhaustive cases and there is no > differential response in the controller or view parts based on them. > > Lille If your goal is to have a set of executable specs that the client can validate by reading them, consider writing them in Cucumber but wiring them directly to the models. George Dinwiddie has blogged about this I think but I can't find the reference. You can combine these with some other scenarios that focus on the behaviour of the user interface if you feel you need that assurance. > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users cheers, Matt http://blog.mattwynne.net +44(0)7974 430184 From walketim at gmail.com Wed Aug 4 15:06:36 2010 From: walketim at gmail.com (Tim Walker) Date: Wed, 4 Aug 2010 13:06:36 -0600 Subject: [rspec-users] [newbie] tradeoffs of direct model access vs. simulated browser (webrat) In-Reply-To: <07fb7a0f-b852-4929-8128-343419aa6fc2@k19g2000yqc.googlegroups.com> References: <07fb7a0f-b852-4929-8128-343419aa6fc2@k19g2000yqc.googlegroups.com> Message-ID: We constantly explore and define this delicate balance. It's not easy and there are no absolutes! One thing that drives us is to approach the "automated testing stack" as a pyramid (not sure where this originates but we used a slide of it when we used to teach executable requirements with fitnesse). The base, widest slice, of the pyramid is your unit tests which you should have the most of. Moving up to controller tests and cucumber tests (not through the user interface). What's left is the smallest piece, the UI tests, which should focus on the UI, probably. Probably because we're constantly breaking the rules. On complex pages with a lot of javascript and xhr callbacks it's important to test the entire stack from the UI through to the data persistence. Tim On Wed, Aug 4, 2010 at 11:44 AM, Lille wrote: > Hi, > > My app involves the elicitation of tabular data over a succession of > controller/model/view groups. The net result is a numeric outcome > based on the entered data (basically, it's a spreadsheet on Rails.) > > Here is the nub of my question about developing such a thing with > RSpec: > > + if I test with a simulated browser approach, my scenarios will need > span multiple controller/model/view triads to confirm the expected > result in as many cases as I feel I need to cover. Basically, an > entire app use-cycle is contained in every scenario -- this doesn't > remind me of anything I've seen in "The RSpec Book", for example. > > + I think I prefer rspec'ing the models directly -- it's concise and I > don't duplicate simulated browser actions for no particular reason. > What's the point of confirming that different data in the same set of > fields is submitted successfully, like 20 times? I'll only simulate > the browser to build the view/controllers and test their behavior when > inputs are inadequate or require differential responses. > > My preferred strategy is sort of like saying to the client: 1) here > are all the numeric outcomes we need to confirm, and 2) here in a > smaller, overlapping set are the behavioral outcomes we need to > confirm > > In short, it seems to me the simulated browser approach (webrat) is > overkill when one is dealing with exhaustive cases and there is no > differential response in the controller or view parts based on them. > > Lille > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From lille.penguini at gmail.com Wed Aug 4 15:48:02 2010 From: lille.penguini at gmail.com (Lille) Date: Wed, 4 Aug 2010 12:48:02 -0700 (PDT) Subject: [rspec-users] [newbie] tradeoffs of direct model access vs. simulated browser (webrat) In-Reply-To: References: <07fb7a0f-b852-4929-8128-343419aa6fc2@k19g2000yqc.googlegroups.com> Message-ID: <9c5c25cb-432f-483d-b053-dd253d265538@t11g2000vbj.googlegroups.com> I appreciate your comments... @Matt - sounds like you're reminding me I can have a unified presentation to the customer if I express all my specs in cucumber, whether any individual scenario takes the simulated browser approach or not. I'm basing my freshman efforts here on 'The RSpec Book', whose beta version suggests that one might BDD their views/models/controllers each in isolation if they hadn't already decided on taking a simulated browser approach with webrat (+ selenium.) I guess I don't think this choice -- as I interpret it from "The RSpec Book' -- is arbitrary: in my case, upon consideration, simulating the browser in every scenario doesn't seem the best approach. Thanks, Lille On Aug 4, 3:06?pm, Tim Walker wrote: > We constantly explore and define this delicate balance. It's not easy > and there are no absolutes! > > One thing that drives us is to approach the "automated testing stack" > as a pyramid (not sure where this originates but we used a slide of it > when we used to teach executable requirements with fitnesse). The > base, widest slice, of the pyramid is your unit tests which you should > have the most of. Moving up to controller tests and cucumber tests > (not through the user interface). What's left is the smallest piece, > the UI tests, which should focus on the UI, probably. Probably because > we're constantly breaking the rules. On complex pages with a lot of > javascript and xhr callbacks it's important to test the entire stack > from the UI through to the data persistence. > > Tim > > > > On Wed, Aug 4, 2010 at 11:44 AM, Lille wrote: > > Hi, > > > My app involves the elicitation of tabular data over a succession of > > controller/model/view groups. The net result is a numeric outcome > > based on the entered data (basically, it's a spreadsheet on Rails.) > > > Here is the nub of my question about developing such a thing with > > RSpec: > > > + if I test with a simulated browser approach, my scenarios will need > > span multiple controller/model/view triads to confirm the expected > > result in as many cases as I feel I need to cover. Basically, an > > entire app use-cycle is contained in every scenario -- this doesn't > > remind me of anything I've seen in "The RSpec Book", for example. > > > + I think I prefer rspec'ing the models directly -- it's concise and I > > don't duplicate simulated browser actions for no particular reason. > > What's the point of confirming that different data in the same set of > > fields is submitted successfully, like 20 times? I'll only simulate > > the browser to build the view/controllers and test their behavior when > > inputs are inadequate or require differential responses. > > > My preferred strategy is sort of like saying to the client: 1) here > > are all the numeric outcomes we need to confirm, and 2) here in a > > smaller, overlapping set are the behavioral outcomes we need to > > confirm > > > In short, it seems to me the simulated browser approach (webrat) is > > overkill when one is dealing with exhaustive cases and there is no > > differential response in the controller or view parts based on them. > > > Lille > > _______________________________________________ > > rspec-users mailing list > > rspec-us... at rubyforge.org > >http://rubyforge.org/mailman/listinfo/rspec-users > > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users From dchelimsky at gmail.com Wed Aug 4 17:01:06 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 4 Aug 2010 16:01:06 -0500 Subject: [rspec-users] [newbie] tradeoffs of direct model access vs. simulated browser (webrat) In-Reply-To: <9c5c25cb-432f-483d-b053-dd253d265538@t11g2000vbj.googlegroups.com> References: <07fb7a0f-b852-4929-8128-343419aa6fc2@k19g2000yqc.googlegroups.com> <9c5c25cb-432f-483d-b053-dd253d265538@t11g2000vbj.googlegroups.com> Message-ID: On Aug 4, 2010, at 2:48 PM, Lille wrote: > I appreciate your comments... > > @Matt - sounds like you're reminding me I can have a unified > presentation to the customer if I express all my specs in cucumber, > whether any individual scenario takes the simulated browser approach > or not. > > I'm basing my freshman efforts here on 'The RSpec Book', whose beta > version suggests that one might BDD their views/models/controllers > each in isolation if they hadn't already decided on taking a simulated > browser approach with webrat (+ selenium.) There is a brief discussion in the views chapter that says that the jury is out on the value of view specs in some contexts and tries to put some guidelines into place about how to approach a decision about doing them or not. But that is only for view specs and it is context specific. It does not apply to controller and model specs, and is not intended to suggest that cukes vs specs is an either/or proposition. There is a picture on the 3rd page of the Rails section of the book that very clearly conveys the process: start with cukes and use them to drive down to view, controller and model specs. > I guess I don't think this > choice -- as I interpret it from "The RSpec Book' -- is arbitrary: in > my case, upon consideration, simulating the browser in every scenario > doesn't seem the best approach. The DMA vs Simulated Browser decision is discussed in several places in the first few chapters of the Rails section as well. There is a section in the Cucumber with Rails chapter that states: "For features that produce many edge cases, it can be useful to drive a few through the Rails stack and the rest using just Direct Model Access for everything." Seems like your conclusion is perfectly aligned with the book's recommendations. Cheers, David > Thanks, > > Lille > > On Aug 4, 3:06 pm, Tim Walker wrote: >> We constantly explore and define this delicate balance. It's not easy >> and there are no absolutes! >> >> One thing that drives us is to approach the "automated testing stack" >> as a pyramid (not sure where this originates but we used a slide of it >> when we used to teach executable requirements with fitnesse). The >> base, widest slice, of the pyramid is your unit tests which you should >> have the most of. Moving up to controller tests and cucumber tests >> (not through the user interface). What's left is the smallest piece, >> the UI tests, which should focus on the UI, probably. Probably because >> we're constantly breaking the rules. On complex pages with a lot of >> javascript and xhr callbacks it's important to test the entire stack >> from the UI through to the data persistence. >> >> Tim >> >> >> >> On Wed, Aug 4, 2010 at 11:44 AM, Lille wrote: >>> Hi, >> >>> My app involves the elicitation of tabular data over a succession of >>> controller/model/view groups. The net result is a numeric outcome >>> based on the entered data (basically, it's a spreadsheet on Rails.) >> >>> Here is the nub of my question about developing such a thing with >>> RSpec: >> >>> + if I test with a simulated browser approach, my scenarios will need >>> span multiple controller/model/view triads to confirm the expected >>> result in as many cases as I feel I need to cover. Basically, an >>> entire app use-cycle is contained in every scenario -- this doesn't >>> remind me of anything I've seen in "The RSpec Book", for example. >> >>> + I think I prefer rspec'ing the models directly -- it's concise and I >>> don't duplicate simulated browser actions for no particular reason. >>> What's the point of confirming that different data in the same set of >>> fields is submitted successfully, like 20 times? I'll only simulate >>> the browser to build the view/controllers and test their behavior when >>> inputs are inadequate or require differential responses. >> >>> My preferred strategy is sort of like saying to the client: 1) here >>> are all the numeric outcomes we need to confirm, and 2) here in a >>> smaller, overlapping set are the behavioral outcomes we need to >>> confirm >> >>> In short, it seems to me the simulated browser approach (webrat) is >>> overkill when one is dealing with exhaustive cases and there is no >>> differential response in the controller or view parts based on them. >> >>> Lille >>> _______________________________________________ >>> rspec-users mailing list >>> rspec-us... at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rspec-users >> >> _______________________________________________ >> rspec-users mailing list >> rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users From lille.penguini at gmail.com Wed Aug 4 17:16:07 2010 From: lille.penguini at gmail.com (Lille) Date: Wed, 4 Aug 2010 14:16:07 -0700 (PDT) Subject: [rspec-users] [newbie] tradeoffs of direct model access vs. simulated browser (webrat) In-Reply-To: References: <07fb7a0f-b852-4929-8128-343419aa6fc2@k19g2000yqc.googlegroups.com> <9c5c25cb-432f-483d-b053-dd253d265538@t11g2000vbj.googlegroups.com> Message-ID: David, Thank you for your kind attention. Yes, I have reviewed the referenced portions of The RSpec Book and see that my interpretation of an opposition bewteen the simulated browser and direct model approaches -- from within cucumber -- was exaggerated. I am glad that you approve of my other reasoning, regardless, and that I found my way to it -- however indirectly -- by reference to your book. I think with all the balls up in the air, I failed to catch that scenarios dwell in features and do not illustrate use cases in the way I have meant it: as navigation through multiple controller/model/view groups to reach a result, e.g., 'purchase', 'loan amount', etc. From now on, when I think of cases where results must be true depending on certain inputs, I will think immediately of cucumber without simulating the browser. Thanks, Lille On Aug 4, 5:01?pm, David Chelimsky wrote: > On Aug 4, 2010, at 2:48 PM, Lille wrote: > > > I appreciate your comments... > > > @Matt - sounds like you're reminding me I can have a unified > > presentation to the customer if I express all my specs in cucumber, > > whether any individual scenario takes the simulated browser approach > > or not. > > > I'm basing my freshman efforts here on 'The RSpec Book', whose beta > > version suggests that one might BDD their views/models/controllers > > each in isolation if they hadn't already decided on taking a simulated > > browser approach with webrat (+ selenium.) > > There is a brief discussion in the views chapter that says that the jury is out on the value of view specs in some contexts and tries to put some guidelines into place about how to approach a decision about doing them or not. But that is only for view specs and it is context specific. It does not apply to controller and model specs, and is not intended to suggest that cukes vs specs is an either/or proposition. > > There is a picture on the 3rd page of the Rails section of the book that very clearly conveys the process: start with cukes and use them to drive down to view, controller and model specs. > > > I guess I don't think this > > choice -- as I interpret it from "The RSpec Book' -- is arbitrary: in > > my case, upon consideration, simulating the browser in every scenario > > doesn't seem the best approach. > > The DMA vs Simulated Browser decision is discussed in several places in the first few chapters of the Rails section as well. There is a section in the Cucumber with Rails chapter that states: "For features that produce many edge cases, it can be useful to drive a few through the Rails stack and the rest using just Direct Model Access for everything." > > Seems like your conclusion is perfectly aligned with the book's recommendations. > > Cheers, > David > > > > > Thanks, > > > Lille > > > On Aug 4, 3:06 pm, Tim Walker wrote: > >> We constantly explore and define this delicate balance. It's not easy > >> and there are no absolutes! > > >> One thing that drives us is to approach the "automated testing stack" > >> as a pyramid (not sure where this originates but we used a slide of it > >> when we used to teach executable requirements with fitnesse). The > >> base, widest slice, of the pyramid is your unit tests which you should > >> have the most of. Moving up to controller tests and cucumber tests > >> (not through the user interface). What's left is the smallest piece, > >> the UI tests, which should focus on the UI, probably. Probably because > >> we're constantly breaking the rules. On complex pages with a lot of > >> javascript and xhr callbacks it's important to test the entire stack > >> from the UI through to the data persistence. > > >> Tim > > >> On Wed, Aug 4, 2010 at 11:44 AM, Lille wrote: > >>> Hi, > > >>> My app involves the elicitation of tabular data over a succession of > >>> controller/model/view groups. The net result is a numeric outcome > >>> based on the entered data (basically, it's a spreadsheet on Rails.) > > >>> Here is the nub of my question about developing such a thing with > >>> RSpec: > > >>> + if I test with a simulated browser approach, my scenarios will need > >>> span multiple controller/model/view triads to confirm the expected > >>> result in as many cases as I feel I need to cover. Basically, an > >>> entire app use-cycle is contained in every scenario -- this doesn't > >>> remind me of anything I've seen in "The RSpec Book", for example. > > >>> + I think I prefer rspec'ing the models directly -- it's concise and I > >>> don't duplicate simulated browser actions for no particular reason. > >>> What's the point of confirming that different data in the same set of > >>> fields is submitted successfully, like 20 times? I'll only simulate > >>> the browser to build the view/controllers and test their behavior when > >>> inputs are inadequate or require differential responses. > > >>> My preferred strategy is sort of like saying to the client: 1) here > >>> are all the numeric outcomes we need to confirm, and 2) here in a > >>> smaller, overlapping set are the behavioral outcomes we need to > >>> confirm > > >>> In short, it seems to me the simulated browser approach (webrat) is > >>> overkill when one is dealing with exhaustive cases and there is no > >>> differential response in the controller or view parts based on them. > > >>> Lille > >>> _______________________________________________ > >>> rspec-users mailing list > >>> rspec-us... at rubyforge.org > >>>http://rubyforge.org/mailman/listinfo/rspec-users > > >> _______________________________________________ > >> rspec-users mailing list > >> rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users > > _______________________________________________ > > rspec-users mailing list > > rspec-us... at rubyforge.org > >http://rubyforge.org/mailman/listinfo/rspec-users > > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users From ahaberbosch at jigsawtech.com Wed Aug 4 19:37:34 2010 From: ahaberbosch at jigsawtech.com (ahaberb) Date: Wed, 4 Aug 2010 16:37:34 -0700 (PDT) Subject: [rspec-users] weird html report samba issue Message-ID: <29351810.post@talk.nabble.com> After several hours of troubleshooting, i've come across a weird issue when saving rspec reports in html format to a samba share using ubuntu hardy, rspec 1.3.0 and ruby 1.9.1. Sometimes the top of the html gets repeated, javascript for the progress bar shows up in the page, or examples get repeated over and over again. If I save the html to a local location, i don't have this problem. Has anyone come across this issue or have an idea of how this could happen? Does spec copy and reload the html on every update? -- View this message in context: http://old.nabble.com/weird-html-report-samba-issue-tp29351810p29351810.html Sent from the rspec-users mailing list archive at Nabble.com. From rick.denatale at gmail.com Wed Aug 4 20:34:15 2010 From: rick.denatale at gmail.com (Rick DeNatale) Date: Wed, 4 Aug 2010 20:34:15 -0400 Subject: [rspec-users] [RSpec] Dynamic reloading with Object.send(:remove_const) In-Reply-To: References: Message-ID: On Wed, Aug 4, 2010 at 12:41 PM, Bruno Cardoso wrote: > Hi, > > I have a function that adds dynamic validations to my models. I use a > combination of ":remove_const" and "load" methods to reload the code > everytime I want to re-apply my dynamic validations. It seams RSpec has > some issues with this. > > I posted here a simpler example code that shows what I mean: > > http://pastie.org/private/ruvgxgipxfge6yzuudbq > > Is it possible to test this with RSpec? Your pastie says # this should have made "Account" go back to its original state but it's not working. # this works outside of RSpec. but I don't understand in what context. In general this won't work in Ruby. Removing the constant only removes the constant from the internal hash which binds the name to the object value. It doesn't change the class object (pointed to by the klass field) of existing instances. Here's a little experiment. The defineFoo method should be the moral equivalent of the load, and the existence of the m2 method is an analogue to whether the class has the validation callback. def defineFoo eval("class Foo;def m1;end;end") end defineFoo foo = Foo.new foo.methods - Object.instance_methods # => ["m1"] Foo.class_eval("def m2;end") foo.methods - Object.instance_methods # => ["m1", "m2"] Object.send(:remove_const, 'Foo') defineFoo foo2 = Foo.new foo2.methods - Object.instance_methods # => ["m1"] foo.methods - Object.instance_methods # => ["m1", "m2"] foo.class == foo2.class # => false -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Github: http://github.com/rubyredrick Twitter: @RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale From dchelimsky at gmail.com Wed Aug 4 23:28:59 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 4 Aug 2010 22:28:59 -0500 Subject: [rspec-users] Evaluating shared example customisation block before shared block In-Reply-To: References: <30EC00AE-9668-48DC-9861-E234B7D87302@patchspace.co.uk> <4977696a-94a3-4467-9048-7c8845731a52@x18g2000pro.googlegroups.com> <9e1b1173-212e-4117-a2b0-fb79752bf9b5@p11g2000prf.googlegroups.com> <3B1DB6C1-87E5-44F8-9E59-B23C66ED02C9@patchspace.co.uk> <91BDC148-2F90-454E-A974-14FB4C2F0FA3@gmail.com> <19E5C86E-C5BF-4518-B132-9EAFA76E969D@patchspace.co.uk> <6A7708A9-FE6D-452B-8002-BB618CF14243@gmail.com> <2115c570-1382-46c4-98bc-66e9fb393ff6@s24g2000pri.googlegroups.com> <1436A904-8C11-4EB1-A056-6F52B7D7864D@gmail.com> Message-ID: <4780CDF9-21B8-47E5-9898-2E9F54FE6AB7@gmail.com> On Aug 4, 2010, at 1:35 PM, Myron Marston wrote: >> I wouldn't even bother to undef those methods. > > If we don't undef the methods, then the semantics of the > #module_eval_with_args (or whatever we call it) will be different on > 1.8.6 and other versions. On 1.8.6, a method definition in the block > would define both an instance method _and_ a class method. Someone > could write a spec against 1.8.6, and accidentally call the class > method, not realizing they've done this, and the spec wouldn't work on > 1.8.7 and above since the class method won't be there. So I think the > undefs are important, and I don't think it adds too much complexity. > >> Something like: >> >> def module_eval_with_args(*args, &block) >> if respond_to?(:module_exec) >> module_exec(*args, &block) >> else >> # custom solution >> end >> end >> >> At that point, as long as all the shared group specs are passing, we're good. Make sense? > > Makes total sense. I'll work on porting this to RSpec, and open an > github issue with a link to the commits when I'm done. FYI - to those paying attention - I merged Myron's changes with support for parameterized shared groups even in 1.8.6. At this point, the customization block is still being eval'd after the shared block, and I'm fairly well convinced this is the right thing, in combination with params to the block. Next release will FINALLY have parameterized shared groups. Sweet! Cheers, David From lists at ruby-forum.com Thu Aug 5 05:16:35 2010 From: lists at ruby-forum.com (Bruno Cardoso) Date: Thu, 5 Aug 2010 11:16:35 +0200 Subject: [rspec-users] [RSpec] Dynamic reloading with Object.send(:remove_const) In-Reply-To: References: Message-ID: <0b10a1e303d44e662191427ce2b670df@ruby-forum.com> Rick Denatale wrote: > Your pastie says > # this should have made "Account" go back to its original state but > it's not working. > # this works outside of RSpec. > > but I don't understand in what context. In general this won't work in > Ruby. > > Removing the constant only removes the constant from the internal hash > which binds the name to the object value. It doesn't change the class > object (pointed to by the klass field) of existing instances. > > Here's a little experiment. The defineFoo method should be the moral > equivalent of the load, and the existence of the m2 method is an > analogue to whether the class has the validation callback. > > def defineFoo > eval("class Foo;def m1;end;end") > end > > defineFoo > > foo = Foo.new > > foo.methods - Object.instance_methods # => ["m1"] > > Foo.class_eval("def m2;end") > foo.methods - Object.instance_methods # => ["m1", "m2"] > > Object.send(:remove_const, 'Foo') > defineFoo > > foo2 = Foo.new > > foo2.methods - Object.instance_methods # => ["m1"] > foo.methods - Object.instance_methods # => ["m1", "m2"] > > foo.class == foo2.class # => false Eureka! You are absolutely right. I completly forgot that I need to instantiate the object again to have the updated definition of the class. Old instances remain the same even after the class definition is changed. Thanks Rick. -- Posted via http://www.ruby-forum.com/. From rick.denatale at gmail.com Thu Aug 5 08:51:03 2010 From: rick.denatale at gmail.com (Rick DeNatale) Date: Thu, 5 Aug 2010 08:51:03 -0400 Subject: [rspec-users] [RSpec] Dynamic reloading with Object.send(:remove_const) In-Reply-To: <0b10a1e303d44e662191427ce2b670df@ruby-forum.com> References: <0b10a1e303d44e662191427ce2b670df@ruby-forum.com> Message-ID: On Thu, Aug 5, 2010 at 5:16 AM, Bruno Cardoso wrote: > Rick Denatale wrote: >> Your pastie says >> # this should have made "Account" go back to its original state but >> it's not working. >> # this works outside of RSpec. >> >> but I don't understand in what context. ?In general this won't work in >> Ruby. >> >> Removing the constant only removes the constant from the internal hash >> which binds the name to the object value. ?It doesn't change the class >> object (pointed to by the klass field) of existing instances. >> >> Here's a little experiment. The defineFoo method should be the moral >> equivalent of the load, and the existence of the m2 method is an >> analogue to whether the class has the validation callback. >> >> def defineFoo >> ? eval("class Foo;def m1;end;end") >> end >> >> defineFoo >> >> foo = Foo.new >> >> foo.methods - Object.instance_methods # => ["m1"] >> >> Foo.class_eval("def m2;end") >> foo.methods - Object.instance_methods # => ["m1", "m2"] >> >> Object.send(:remove_const, 'Foo') >> defineFoo >> >> foo2 = Foo.new >> >> foo2.methods - Object.instance_methods # => ["m1"] >> foo.methods - Object.instance_methods # => ["m1", "m2"] >> >> foo.class == foo2.class # => false > > Eureka! > > You are absolutely right. I completly forgot that I need to instantiate > the object again to have the updated definition of the class. Old > instances remain the same even after the class definition is changed. > > Thanks Rick. That's all well and good, but I have to step back and say that I detect a code smell called "stupid ruby tricks" here. This type of dynamic class alteration can lead to all kinds of trouble trying to understand, and debug the code. Debugging Rails callbacks is tough enough even without such unorthodox code. If you pursue this technique I predict several frustrating debugging sessions in your future. Why not just use the AR API and start with something like class Account < ActiveRecord::Base class << self attribute_accessor :validating_description end validates_numericality_of :description :if => lambda { |account| Account.validating_description} end Then just use Account.validating_description = true to turn it off and Account.validating_description = false to turn it off? Even then, I'm not sure I understand the use case for turning this off at the class label, usually such conditional validations are done on the basis of instance state, which is why the proc associated with the :if and :unless options takes the instance as an argument, of course the proc is free to ignore that as I've done here. But it's your use case, and other than poking you to think about whether you want to do it on a class or instance basis, I'll defer to your superior domain knowledge. -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Github: http://github.com/rubyredrick Twitter: @RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale From gudleik at gmail.com Thu Aug 5 10:32:08 2010 From: gudleik at gmail.com (Gudleik Rasch) Date: Thu, 5 Aug 2010 16:32:08 +0200 Subject: [rspec-users] Macros and accessing block-variables (rspec2) Message-ID: Hi, I'm trying to create an rspec macro (for rspec2) but it cannot access variables defined in a before-block. Am I missing something or is it supposed to be like that? Here's a full example: http://gist.github.com/509802 -- gudleik From lists at iDIAcomputing.com Thu Aug 5 11:03:49 2010 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Thu, 05 Aug 2010 11:03:49 -0400 Subject: [rspec-users] [newbie] tradeoffs of direct model access vs. simulated browser (webrat) In-Reply-To: <6C73ECDD-8FD9-40D9-BB80-967BA9BE9CEF@mattwynne.net> References: <07fb7a0f-b852-4929-8128-343419aa6fc2@k19g2000yqc.googlegroups.com> <6C73ECDD-8FD9-40D9-BB80-967BA9BE9CEF@mattwynne.net> Message-ID: <4C5AD2D5.6030505@iDIAcomputing.com> Matt, Lille, On 8/4/10 2:58 PM, Matt Wynne wrote: > > On 4 Aug 2010, at 18:44, Lille wrote: > >> Hi, >> >> My app involves the elicitation of tabular data over a succession of >> controller/model/view groups. The net result is a numeric outcome >> based on the entered data (basically, it's a spreadsheet on Rails.) >> >> Here is the nub of my question about developing such a thing with >> RSpec: >> >> + if I test with a simulated browser approach, my scenarios will need >> span multiple controller/model/view triads to confirm the expected >> result in as many cases as I feel I need to cover. Basically, an >> entire app use-cycle is contained in every scenario -- this doesn't >> remind me of anything I've seen in "The RSpec Book", for example. >> >> + I think I prefer rspec'ing the models directly -- it's concise and I >> don't duplicate simulated browser actions for no particular reason. >> What's the point of confirming that different data in the same set of >> fields is submitted successfully, like 20 times? I'll only simulate >> the browser to build the view/controllers and test their behavior when >> inputs are inadequate or require differential responses. >> >> My preferred strategy is sort of like saying to the client: 1) here >> are all the numeric outcomes we need to confirm, and 2) here in a >> smaller, overlapping set are the behavioral outcomes we need to >> confirm >> >> In short, it seems to me the simulated browser approach (webrat) is >> overkill when one is dealing with exhaustive cases and there is no >> differential response in the controller or view parts based on them. >> >> Lille > > If your goal is to have a set of executable specs that the client can > validate by reading them, consider writing them in Cucumber but > wiring them directly to the models. Yes, I'm a big proponent of verifying business rules at the lowest level possible. It's easier to do so, and it also helps cover all the possibiities. > George Dinwiddie has blogged about this I think but I can't find the > reference. I've certainly talked a lot on acceptance testing at multiple levels, but I don't think I've blogged on it, yet. I should remedy that. > You can combine these with some other scenarios that focus on the > behaviour of the user interface if you feel you need that assurance. Yes, you'll probably always need at least one scenario to verify that things are wired up correctly. - George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From myron.marston at gmail.com Thu Aug 5 20:24:27 2010 From: myron.marston at gmail.com (Myron Marston) Date: Thu, 5 Aug 2010 17:24:27 -0700 (PDT) Subject: [rspec-users] Macros and accessing block-variables (rspec2) In-Reply-To: References: Message-ID: The before block and the macro declaration get run in different contexts. In the before block, self is an instance of the example group. Your macro declaration runs with self set to the example group itself. It's the difference between an instance variable of a Class instance (since Classes are objects, too), and an instance variable of an instance of a class. Myron On Aug 5, 7:32?am, Gudleik Rasch wrote: > Hi, > > I'm trying to create an rspec macro (for rspec2) but it cannot access > variables defined in a before-block. > Am I missing something or is it supposed to be like that? > > Here's a full example:http://gist.github.com/509802 > > -- > gudleik > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users From anexiole at gmail.com Thu Aug 5 22:52:24 2010 From: anexiole at gmail.com (ct9a) Date: Thu, 5 Aug 2010 19:52:24 -0700 (PDT) Subject: [rspec-users] New bie question: Why use assert_equal when there are comparison operators in Rspec? Message-ID: <1134c246-15d4-4539-94bc-4d422dbea514@h40g2000pro.googlegroups.com> hi guys, I'm reading up on Rspec, Mocha and some related material to put BDD in my new rails app. I have also checked out Ryan Bates' railscasts on rspec (that's how I got to know about Mocha). Reading up on the Rspec's main site, the main example in http://rspec.rubyforge.org/rspec/1.3.0/ does not show any use of assert_equals. Rather it just uses the "==" comparison operators. Here's an extract: ============ Extract begin =========================== it "reduces its balance by the transfer amount" do source = Account.new(50, :USD) target = stub('target account') source.transfer(5, :USD).to(target) source.balance.should == Money.new(45, :USD) <----- here end end end ============ Extract end =========================== Newbie question (don't shoot me cause I tried reading up and can't find out why): Why do folks still use assert_equal if the comparison operators (apart from that there's a Test::Unit::Assertions module (http://ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/ Assertions.html) written for it)? From ashley.moran at patchspace.co.uk Fri Aug 6 04:16:15 2010 From: ashley.moran at patchspace.co.uk (Ashley Moran) Date: Fri, 6 Aug 2010 09:16:15 +0100 Subject: [rspec-users] Evaluating shared example customisation block before shared block In-Reply-To: References: <30EC00AE-9668-48DC-9861-E234B7D87302@patchspace.co.uk> <09CFF5F4-E1F8-417E-9781-C264B44F8081@gmail.com> <92EF66E4-3748-462D-BC85-EEF0BF51C223@patchspace.co.uk> <2A82081A-ED3E-423B-A068-3FB067F8C4B6@gmail.com> <81E33C70-68CD-4415-BC9E-23D0F2B6F0FB@patchspace.co.uk> <621BAF47-4CEC-4364-B706-6DFF7C9155A1@gmail.com> <529E5DDF-1E2C-4F38-9DD4-DAD1350218FF@patchspace.co.uk> <4977696a-94a3-4467-9048-7c8845731a52@x18g2000pro.googlegroups.com> <9e1b1173-212e-4117-a2b0-fb79752bf9b5@p11g2000prf.googlegroups.com> <3B1DB6C1-87E5-44F8-9E59-B23C66ED02C9@patchspace.co.uk> <91BDC148-2F90-454E-A974-14FB4C2F0FA3@gmail.com> <19E5C86E-C5BF-4518-B132-9EAFA76E969D@patchspace.co.uk> <6A7708A9-FE6D-452B-8002-BB618CF14243@gmail.com> <417477F5-605B-46C7-B37F-E20DD4BA163E@patchspace.co.uk> Message-ID: <9FF45E71-D656-4FD3-B846-9CB45357CE68@patchspace.co.uk> On Aug 04, 2010, at 12:41 pm, David Chelimsky wrote: > What happens if the shared spec author really wants it to just be a hash? Do you think that's a valid use case? It could get in the way, then, I guess. You'd always have the original hash parameter if you wanted to use the method, but I guess it could cause trouble if you did this, or similar: shared_examples_for "a foo container" do |foo, options = {}| it "has a #{foo}" do; end end describe Bar do it_should_behave_like "a foo container", 1, foo: 2 end I'll probably play with this idea in my own code. There's definitely no need worry about it now, being able to pass arguments to shared example groups is 90% of the win for me. Cheers Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran From ashley.moran at patchspace.co.uk Fri Aug 6 04:18:03 2010 From: ashley.moran at patchspace.co.uk (Ashley Moran) Date: Fri, 6 Aug 2010 09:18:03 +0100 Subject: [rspec-users] Evaluating shared example customisation block before shared block In-Reply-To: <4780CDF9-21B8-47E5-9898-2E9F54FE6AB7@gmail.com> References: <30EC00AE-9668-48DC-9861-E234B7D87302@patchspace.co.uk> <4977696a-94a3-4467-9048-7c8845731a52@x18g2000pro.googlegroups.com> <9e1b1173-212e-4117-a2b0-fb79752bf9b5@p11g2000prf.googlegroups.com> <3B1DB6C1-87E5-44F8-9E59-B23C66ED02C9@patchspace.co.uk> <91BDC148-2F90-454E-A974-14FB4C2F0FA3@gmail.com> <19E5C86E-C5BF-4518-B132-9EAFA76E969D@patchspace.co.uk> <6A7708A9-FE6D-452B-8002-BB618CF14243@gmail.com> <2115c570-1382-46c4-98bc-66e9fb393ff6@s24g2000pri.googlegroups.com> <1436A904-8C11-4EB1-A056-6F52B7D7864D@gmail.com> <4780CDF9-21B8-47E5-9898-2E9F54FE6AB7@gmail.com> Message-ID: <863025E2-9D4E-43D6-880F-EA8025D3C840@patchspace.co.uk> On Aug 05, 2010, at 4:28 am, David Chelimsky wrote: > At this point, the customization block is still being eval'd after the shared block, and I'm fairly well convinced this is the right thing, in combination with params to the block. I don't think it makes any different any more, at least not to me. The only thing you can't do is use class methods in shared example descriptions, but you don't need to do that any more now anyway. > Next release will FINALLY have parameterized shared groups. Sweet! Brilliant :-) What's the current release plan? Cheers Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran From ashley.moran at patchspace.co.uk Fri Aug 6 05:27:34 2010 From: ashley.moran at patchspace.co.uk (Ashley Moran) Date: Fri, 6 Aug 2010 10:27:34 +0100 Subject: [rspec-users] Macros and accessing block-variables (rspec2) In-Reply-To: References: Message-ID: <7E216298-433C-45BC-8AD0-96FDA8AD6C91@patchspace.co.uk> On Aug 06, 2010, at 1:24 am, Myron Marston wrote: > It's the difference between an instance variable of a Class instance > (since Classes are objects, too), and an instance variable of an > instance of a class. I talked a .Net dev friend of mine through instance ivar + class ivar + class variables last weekend. His response was something along the lines of "Woah!" :) Gudleik - the simplest, readable change I can think of is to make the answer a constant[1]. The answer is really a property of the spec, not of the examples, so it doesn't belong in the `before` block. But I suspect the example you've given is a simplified version of something more complex, so real-world solution may be different. HTH Ash [1] http://gist.github.com/511087 -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran From ashley.moran at patchspace.co.uk Fri Aug 6 05:32:55 2010 From: ashley.moran at patchspace.co.uk (Ashley Moran) Date: Fri, 6 Aug 2010 10:32:55 +0100 Subject: [rspec-users] New bie question: Why use assert_equal when there are comparison operators in Rspec? In-Reply-To: <1134c246-15d4-4539-94bc-4d422dbea514@h40g2000pro.googlegroups.com> References: <1134c246-15d4-4539-94bc-4d422dbea514@h40g2000pro.googlegroups.com> Message-ID: <8164C43D-B986-4BA1-8512-DCBCA17C2C36@patchspace.co.uk> On Aug 06, 2010, at 3:52 am, ct9a wrote: > Reading up on the Rspec's main site, the main example in > http://rspec.rubyforge.org/rspec/1.3.0/ does not show any use of > assert_equals. Rather it just uses the "==" comparison operators. > Here's an extract: assert_equals is part of Test::Unit, not RSpec. You can't use assert_equals in RSpec unless you also have Test::Unit loaded. The default Rails test suite setup is based on Test::Unit, so you have access to both. (RSpec it designed to integrate with it.) There's no reason to use assert_equals unless you want to, and personally I'd avoid miking the two styles. HTH Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran From dchelimsky at gmail.com Fri Aug 6 06:58:28 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 6 Aug 2010 05:58:28 -0500 Subject: [rspec-users] Evaluating shared example customisation block before shared block In-Reply-To: <863025E2-9D4E-43D6-880F-EA8025D3C840@patchspace.co.uk> References: <30EC00AE-9668-48DC-9861-E234B7D87302@patchspace.co.uk> <4977696a-94a3-4467-9048-7c8845731a52@x18g2000pro.googlegroups.com> <9e1b1173-212e-4117-a2b0-fb79752bf9b5@p11g2000prf.googlegroups.com> <3B1DB6C1-87E5-44F8-9E59-B23C66ED02C9@patchspace.co.uk> <91BDC148-2F90-454E-A974-14FB4C2F0FA3@gmail.com> <19E5C86E-C5BF-4518-B132-9EAFA76E969D@patchspace.co.uk> <6A7708A9-FE6D-452B-8002-BB618CF14243@gmail.com> <2115c570-1382-46c4-98bc-66e9fb393ff6@s24g2000pri.googlegroups.com> <1436A904-8C11-4EB1-A056-6F52B7D7864D@gmail.com> <4780CDF9-21B8-47E5-9898-2E9F54FE6AB7@gmail.com> <863025E2-9D4E-43D6-880F-EA8025D3C840@patchspace.co.uk> Message-ID: On Aug 6, 2010, at 3:18 AM, Ashley Moran wrote: > > On Aug 05, 2010, at 4:28 am, David Chelimsky wrote: > >> At this point, the customization block is still being eval'd after the shared block, and I'm fairly well convinced this is the right thing, in combination with params to the block. > > I don't think it makes any different any more, at least not to me. The only thing you can't do is use class methods in shared example descriptions, but you don't need to do that any more now anyway. > >> Next release will FINALLY have parameterized shared groups. Sweet! > > Brilliant :-) What's the current release plan? Barring the unforeseen, I'll knock out beta.20 this weekend. David > > Cheers > Ash From ashley.moran at patchspace.co.uk Fri Aug 6 07:00:42 2010 From: ashley.moran at patchspace.co.uk (Ashley Moran) Date: Fri, 6 Aug 2010 12:00:42 +0100 Subject: [rspec-users] Evaluating shared example customisation block before shared block In-Reply-To: References: <30EC00AE-9668-48DC-9861-E234B7D87302@patchspace.co.uk> <4977696a-94a3-4467-9048-7c8845731a52@x18g2000pro.googlegroups.com> <9e1b1173-212e-4117-a2b0-fb79752bf9b5@p11g2000prf.googlegroups.com> <3B1DB6C1-87E5-44F8-9E59-B23C66ED02C9@patchspace.co.uk> <91BDC148-2F90-454E-A974-14FB4C2F0FA3@gmail.com> <19E5C86E-C5BF-4518-B132-9EAFA76E969D@patchspace.co.uk> <6A7708A9-FE6D-452B-8002-BB618CF14243@gmail.com> <2115c570-1382-46c4-98bc-66e9fb393ff6@s24g2000pri.googlegroups.com> <1436A904-8C11-4EB1-A056-6F52B7D7864D@gmail.com> <4780CDF9-21B8-47E5-9898-2E9F54FE6AB7@gmail.com> <863025E2-9D4E-43D6-880F-EA8025D3C840@patchspace.co.uk> Message-ID: On Aug 06, 2010, at 11:58 am, David Chelimsky wrote: > Barring the unforeseen, I'll knock out beta.20 this weekend. Cool, ta! Cheers Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran From lists at ruby-forum.com Fri Aug 6 13:06:16 2010 From: lists at ruby-forum.com (Subhash Mishra) Date: Fri, 6 Aug 2010 19:06:16 +0200 Subject: [rspec-users] Cucumber Development Message-ID: <27a9fffbf29b8b2650e597607c4cd1b0@ruby-forum.com> Hi All, I'm using cucumber for some time. it's quite good and i want to do some further development, so that user can even parse the arguments. I'm looking for developers guide of cucumber or even if some one knows the close by file to change for this requirement would be very helpful. any response about cucumber coding structure would be helpful. -- Posted via http://www.ruby-forum.com/. From dchelimsky at gmail.com Fri Aug 6 13:08:08 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 6 Aug 2010 12:08:08 -0500 Subject: [rspec-users] Cucumber Development In-Reply-To: <27a9fffbf29b8b2650e597607c4cd1b0@ruby-forum.com> References: <27a9fffbf29b8b2650e597607c4cd1b0@ruby-forum.com> Message-ID: On Aug 6, 2010, at 12:06 PM, Subhash Mishra wrote: > Hi All, > I'm using cucumber for some time. it's quite good and i want to do some > further development, so that user can even parse the arguments. I'm > looking for developers guide of cucumber or even if some one knows the > close by file to change for this requirement would be very helpful. > any response about cucumber coding structure would be helpful. Cucumber has its own mailing list/user group: http://groups.google.com/group/cukes. I'd recommend asking there, though you'll probably want to be a bit more specific about your question. Cheers, David From lists at ruby-forum.com Fri Aug 6 13:28:32 2010 From: lists at ruby-forum.com (Subhash Mishra) Date: Fri, 6 Aug 2010 19:28:32 +0200 Subject: [rspec-users] Cucumber Development In-Reply-To: References: <27a9fffbf29b8b2650e597607c4cd1b0@ruby-forum.com> Message-ID: <5ee2265ed07ce619bee0baea6333aed0@ruby-forum.com> David Chelimsky wrote: > On Aug 6, 2010, at 12:06 PM, Subhash Mishra wrote: > >> Hi All, >> I'm using cucumber for some time. it's quite good and i want to do some >> further development, so that user can even parse the arguments. I'm >> looking for developers guide of cucumber or even if some one knows the >> close by file to change for this requirement would be very helpful. >> any response about cucumber coding structure would be helpful. > > Cucumber has its own mailing list/user group: > http://groups.google.com/group/cukes. > > I'd recommend asking there, though you'll probably want to be a bit more > specific about your question. > > Cheers, > David Thanx, Well as far as concern of my problem is only this much that i want to parse argument of cucumber sentence before calling sentence definition e.g. suppose i have a cucumber sentence When I press "" and there corresponding definition When /^I press "([^\"]*)"$/ do |arg1| ruby code end where ever above cucumber sentence will be encountered, the actual ruby code is going to be called and is going to be passed in 'arg1'. i want to do some operation on this before being supplied to arg1. :-) -- Posted via http://www.ruby-forum.com/. From dchelimsky at gmail.com Fri Aug 6 13:39:00 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 6 Aug 2010 12:39:00 -0500 Subject: [rspec-users] Cucumber Development In-Reply-To: <5ee2265ed07ce619bee0baea6333aed0@ruby-forum.com> References: <27a9fffbf29b8b2650e597607c4cd1b0@ruby-forum.com> <5ee2265ed07ce619bee0baea6333aed0@ruby-forum.com> Message-ID: <9BDA8FB0-1797-49A5-868D-F1FEF3E09CAF@gmail.com> On Aug 6, 2010, at 12:28 PM, Subhash Mishra wrote: > David Chelimsky wrote: >> On Aug 6, 2010, at 12:06 PM, Subhash Mishra wrote: >> >>> Hi All, >>> I'm using cucumber for some time. it's quite good and i want to do some >>> further development, so that user can even parse the arguments. I'm >>> looking for developers guide of cucumber or even if some one knows the >>> close by file to change for this requirement would be very helpful. >>> any response about cucumber coding structure would be helpful. >> >> Cucumber has its own mailing list/user group: >> http://groups.google.com/group/cukes. >> >> I'd recommend asking there, though you'll probably want to be a bit more >> specific about your question. >> >> Cheers, >> David > > Thanx, > Well as far as concern of my problem is only this much that i want to > parse argument of cucumber sentence before calling sentence definition > e.g. suppose i have a cucumber sentence > When I press "" > and there corresponding definition > When /^I press "([^\"]*)"$/ do |arg1| > ruby code > end > where ever above cucumber sentence will be encountered, the actual ruby > code is going to be called and is going to be passed in > 'arg1'. i want to do some operation on this before being > supplied to arg1. > :-) Please post this to the Cucumber user group: http://groups.google.com/group/cukes. From ashley.moran at patchspace.co.uk Fri Aug 6 13:49:12 2010 From: ashley.moran at patchspace.co.uk (Ashley Moran) Date: Fri, 6 Aug 2010 18:49:12 +0100 Subject: [rspec-users] Cucumber Development In-Reply-To: <5ee2265ed07ce619bee0baea6333aed0@ruby-forum.com> References: <27a9fffbf29b8b2650e597607c4cd1b0@ruby-forum.com> <5ee2265ed07ce619bee0baea6333aed0@ruby-forum.com> Message-ID: On 6 Aug 2010, at 18:28, Subhash Mishra wrote: >> Cucumber has its own mailing list/user group: >> http://groups.google.com/group/cukes. >> >> I'd recommend asking there, though you'll probably want to be a bit more >> specific about your question. >> >> Cheers, >> David > > Thanx, > Well as far as concern of my problem is only this much that i want to > parse argument of cucumber sentence before calling sentence definition > e.g. suppose i have a cucumber sentence > When I press "" > and there corresponding definition > When /^I press "([^\"]*)"$/ do |arg1| > ruby code > end > where ever above cucumber sentence will be encountered, the actual ruby > code is going to be called and is going to be passed in > 'arg1'. i want to do some operation on this before being > supplied to arg1. > :-) Here we go again. I think what David meant is that you should ask on the Cucumber list, as that's where the Cucumber developers hang out. They are the people you need to ask to get an authoritative answer. -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran -------------- next part -------------- An HTML attachment was scrubbed... URL: From mguterl at gmail.com Fri Aug 6 15:44:10 2010 From: mguterl at gmail.com (Michael Guterl) Date: Fri, 6 Aug 2010 15:44:10 -0400 Subject: [rspec-users] RSpec uses at_exit - forks and stuff In-Reply-To: References: <128D01B3-24F7-4D16-8F7F-C77517EABE23@gmail.com> Message-ID: Andrew, On Thu, Jul 8, 2010 at 7:47 AM, Andrew Premdas wrote: > > > On 8 July 2010 11:46, David Chelimsky wrote: >> >> On Jul 8, 2010, at 4:24 AM, Andrew Premdas wrote: >> >> On 8 July 2010 01:01, David Chelimsky wrote: >>> >>> On Jul 7, 2010, at 8:22 AM, Andrew Premdas wrote: >>> >>> > Hi there. >>> > >>> > My understanding (which is limited) is that rspec uses at_exit to run >>> > its specs. I don't really know why - could somoene explain? >>> >>> The initial motivation was that it makes it easy to make sure it works >>> whether you run it with the ruby command or the rspec command. Over the >>> years it has caused some trouble though, so I'd be interested in a different >>> solution. >>> >>> > My problem with this behaviour is that I would like the running of a >>> > spec to start an instance of solr (using Sunspot) if one is not running. The >>> > problem with this is that Sunspot forks to start solr, and when these forks >>> > exit they run my specs. At best this causes specs to be run more than once, >>> > at worst it causes specs to fail in their hundreds. >>> > >>> > I can fix this by adding an at_exit for each fork ... >>> > >>> > ? ? fork do >>> > ? ? ? ... >>> > ? ? ? at_exit { exit! } >>> > ? ? end >>> > >>> > but this means changing the Sunspot code, which I really shouldn't have >>> > to do to run specs. So is their anything else I can do. Ideally in >>> > spec_helper or another rspec support file. >>> >>> I added RSpec::Core::Runner.disable_autorun! to beta.16 in order to solve >>> a similar problem. No guarantees it will stay there if I come up with a >>> better way to deal with supporting multiple entry points, but if I remove it >>> I'll formally deprecate it (so you're safe to use it). >>> >>> HTH, >>> David >>> >> Thanks for your reply David. Does this only apply only to rspec2? >> >> Yes. >> >> (the beta 16 seems a bit of a giveaway). Is there something I can do with >> rspec 1x. >> >> Not sure, but I really don't have time to experiment with this right now - >> sorry. If you do, and come up with something, please post it back and I'll >> look at merging it. >> >> I've tried commenting out ?require 'spec/autorun', but that had no effect. >> Is there is something I could do like put a monkey patch in spec helper. >> On a related note, can rspec 2 be used on rails 2x projects >> >> Not quite yet. Definitely in the plan, but probably not going to happen >> until the fall unless someone other than me makes it so. >> There is?http://github.com/rsanheim/rspec-rails23, which works with a >> subset of rspec-rails-2 functionality and only up to beta.8. This is likely >> NOT to be the basis for an official rspec2-rails2 gem so please don't use >> this expecting a smooth upgrade path once such a gem exists. >> HTH, >> David > > Thanks for your input David, current fix is to monkey patch the offending > code and add ?at_exit { exit! } to the end of each fork block. Not pretty, > but it will do for now. Clearly we will have to bite the bullet and go to > rails3 rspec2 at some point, struggling to keep up with the pace of change > at the moment. While I came up with my own solution to this problem, I would love to compare solutions. Here's what I came up with: http://gist.github.com/511874 Best regards, Michael Guterl From abder.rahman.ali at gmail.com Fri Aug 6 13:39:24 2010 From: abder.rahman.ali at gmail.com (SWEngineer) Date: Fri, 6 Aug 2010 10:39:24 -0700 (PDT) Subject: [rspec-users] Could not find generator rspec:install. Message-ID: I'm trying to follow this tutorial here: http://railstutorial.org/chapters/static-pages#top When I run: $ rails generate rspec:install I get: Could not find generator rspec:install. What could be the problem? Thanks. From dchelimsky at gmail.com Sat Aug 7 09:06:03 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 7 Aug 2010 08:06:03 -0500 Subject: [rspec-users] Could not find generator rspec:install. In-Reply-To: References: Message-ID: <3FC276A9-EB11-4DC6-BAFA-B084697753CE@gmail.com> On Aug 6, 2010, at 12:39 PM, SWEngineer wrote: > I'm trying to follow this tutorial here: http://railstutorial.org/chapters/static-pages#top > > When I run: > > $ rails generate rspec:install > > I get: > > Could not find generator rspec:install. > > What could be the problem? The tutorial shows the rspec-rails gem configured in both the :development and :test groups. Do you have it set up that way? > > Thanks. > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users From kmandrup.github at gmail.com Sat Aug 7 09:23:50 2010 From: kmandrup.github at gmail.com (Kristian Mandrup) Date: Sat, 7 Aug 2010 06:23:50 -0700 (PDT) Subject: [rspec-users] How do I extend ExampleGroup in Rspec 2? Message-ID: <39a3ce5e-b42d-41f8-be38-b39fa40eacee@f6g2000yqa.googlegroups.com> I simply want all methods of a module to be always available within the context of an Example group. module RSpec module Generator def with_generator &block ... end def setup_generator test_method_name=nil, &block ... end end end How do I achieve this? In RSpec 1 I think you would use ExampleGroupFactory I thought I could do it something like this with RSpec 2? RSpec.configure do |c| c.extend RSpec::Generator end I want to be able to do something like this before :each do setup_generator 'migration_generator' do tests MigrationGenerator end end it "should generate create_user migration" do with_generator do |g| ... end Whereas now I have to do it like this, which I find a bit ugly and cumbersome it "should generate create_user migration" do RSpec::Generator.with_generator do |g| name = 'create_users' end end Thanks. From dchelimsky at gmail.com Sat Aug 7 10:09:50 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 7 Aug 2010 09:09:50 -0500 Subject: [rspec-users] How do I extend ExampleGroup in Rspec 2? In-Reply-To: <39a3ce5e-b42d-41f8-be38-b39fa40eacee@f6g2000yqa.googlegroups.com> References: <39a3ce5e-b42d-41f8-be38-b39fa40eacee@f6g2000yqa.googlegroups.com> Message-ID: On Aug 7, 2010, at 8:23 AM, Kristian Mandrup wrote: > I simply want all methods of a module to be always available within > the context of an Example group. > > module RSpec > module Generator > def with_generator &block > ... > end > > def setup_generator test_method_name=nil, &block > ... > end > end > end > > How do I achieve this? > > In RSpec 1 I think you would use ExampleGroupFactory > > I thought I could do it something like this with RSpec 2? > > RSpec.configure do |c| > c.extend RSpec::Generator > end > > I want to be able to do something like this > > before :each do before hooks are eval'd in the scope of an example, which is an _instance_ of the example group class. Try using include instead of extend: c.include RSpec::Generator HTH, David > setup_generator 'migration_generator' do > tests MigrationGenerator > end > end > > it "should generate create_user migration" do > with_generator do |g| > ... > end > > Whereas now I have to do it like this, which I find a bit ugly and > cumbersome > > it "should generate create_user migration" do > RSpec::Generator.with_generator do |g| > name = 'create_users' > end > end > > Thanks. > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users From kmandrup.github at gmail.com Sat Aug 7 11:04:16 2010 From: kmandrup.github at gmail.com (Kristian Mandrup) Date: Sat, 7 Aug 2010 08:04:16 -0700 (PDT) Subject: [rspec-users] How do I extend ExampleGroup in Rspec 2? In-Reply-To: References: <39a3ce5e-b42d-41f8-be38-b39fa40eacee@f6g2000yqa.googlegroups.com> Message-ID: <05a66d4c-bd13-4ac9-aeca-216b399fd91c@d17g2000yqb.googlegroups.com> Thanks, but it didn't work. The following somewhat ugly hack works however. module RSpec::Core class ExampleGroup def with_generator &block RSpec::Generator.with_generator &block end def setup_generator test_method_name=nil, &block RSpec::Generator.setup_generator test_method_name, &block end end end On Aug 7, 4:09?pm, David Chelimsky wrote: > On Aug 7, 2010, at 8:23 AM, Kristian Mandrup wrote: > > > > > I simply want all methods of a module to be always available within > > the context of an Example group. > > > module RSpec > > ?module Generator > > ? ? ?def with_generator &block > > ? ? ? ... > > ? ? ?end > > > ? ? ?def setup_generator test_method_name=nil, &block > > ? ? ? ?... > > ? ? ?end > > ?end > > end > > > How do I achieve this? > > > In RSpec 1 I think you would use ExampleGroupFactory > > > I thought I could do it something like this with RSpec 2? > > > RSpec.configure do |c| > > c.extend RSpec::Generator > > end > > > I want to be able to do something like this > > > ?before :each do > > before hooks are eval'd in the scope of an example, which is an _instance_ of the example group class. Try using include instead of extend: > > c.include RSpec::Generator > > HTH, > David > > > > > ? ?setup_generator 'migration_generator' do > > ? ? ?tests MigrationGenerator > > ? ?end > > ?end > > > ?it "should generate create_user migration" do > > ? ?with_generator do |g| > > ? ? ?... > > ?end > > > Whereas now I have to do it like this, which I find a bit ugly and > > cumbersome > > > ?it "should generate create_user migration" do > > ? ?RSpec::Generator.with_generator do |g| > > ? ? ?name = 'create_users' > > ? ?end > > ?end > > > Thanks. > > _______________________________________________ > > rspec-users mailing list > > rspec-us... at rubyforge.org > >http://rubyforge.org/mailman/listinfo/rspec-users > > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users From dchelimsky at gmail.com Sat Aug 7 11:15:27 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 7 Aug 2010 10:15:27 -0500 Subject: [rspec-users] How do I extend ExampleGroup in Rspec 2? In-Reply-To: <05a66d4c-bd13-4ac9-aeca-216b399fd91c@d17g2000yqb.googlegroups.com> References: <39a3ce5e-b42d-41f8-be38-b39fa40eacee@f6g2000yqa.googlegroups.com> <05a66d4c-bd13-4ac9-aeca-216b399fd91c@d17g2000yqb.googlegroups.com> Message-ID: On Aug 7, 2010, at 10:04 AM, Kristian Mandrup wrote: > Thanks, but it didn't work. The following somewhat ugly hack works > however. > > module RSpec::Core > class ExampleGroup > def with_generator &block > RSpec::Generator.with_generator &block > end > > def setup_generator test_method_name=nil, &block > RSpec::Generator.setup_generator test_method_name, &block > end > end > end Please submit an issue for this - it should work as I suggested: http://github.com/rspec/rspec-core/issues > > > On Aug 7, 4:09 pm, David Chelimsky wrote: >> On Aug 7, 2010, at 8:23 AM, Kristian Mandrup wrote: >> >> >> >>> I simply want all methods of a module to be always available within >>> the context of an Example group. >> >>> module RSpec >>> module Generator >>> def with_generator &block >>> ... >>> end >> >>> def setup_generator test_method_name=nil, &block >>> ... >>> end >>> end >>> end >> >>> How do I achieve this? >> >>> In RSpec 1 I think you would use ExampleGroupFactory >> >>> I thought I could do it something like this with RSpec 2? >> >>> RSpec.configure do |c| >>> c.extend RSpec::Generator >>> end >> >>> I want to be able to do something like this >> >>> before :each do >> >> before hooks are eval'd in the scope of an example, which is an _instance_ of the example group class. Try using include instead of extend: >> >> c.include RSpec::Generator >> >> HTH, >> David >> >> >> >>> setup_generator 'migration_generator' do >>> tests MigrationGenerator >>> end >>> end >> >>> it "should generate create_user migration" do >>> with_generator do |g| >>> ... >>> end >> >>> Whereas now I have to do it like this, which I find a bit ugly and >>> cumbersome >> >>> it "should generate create_user migration" do >>> RSpec::Generator.with_generator do |g| >>> name = 'create_users' >>> end >>> end >> >>> Thanks. >>> _______________________________________________ >>> rspec-users mailing list >>> rspec-us... at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rspec-users >> >> _______________________________________________ >> rspec-users mailing list >> rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users From dchelimsky at gmail.com Sat Aug 7 11:17:29 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 7 Aug 2010 10:17:29 -0500 Subject: [rspec-users] How do I extend ExampleGroup in Rspec 2? In-Reply-To: References: <39a3ce5e-b42d-41f8-be38-b39fa40eacee@f6g2000yqa.googlegroups.com> <05a66d4c-bd13-4ac9-aeca-216b399fd91c@d17g2000yqb.googlegroups.com> Message-ID: <7360DDED-A917-4B5A-9E1E-09E43616E73A@gmail.com> On Aug 7, 2010, at 10:15 AM, David Chelimsky wrote: > On Aug 7, 2010, at 10:04 AM, Kristian Mandrup wrote: > >> Thanks, but it didn't work. The following somewhat ugly hack works >> however. >> >> module RSpec::Core >> class ExampleGroup >> def with_generator &block >> RSpec::Generator.with_generator &block >> end >> >> def setup_generator test_method_name=nil, &block >> RSpec::Generator.setup_generator test_method_name, &block >> end >> end >> end > > Please submit an issue for this - it should work as I suggested: http://github.com/rspec/rspec-core/issues FYI - this passes for me: module Foo def bar yield end end RSpec.configure do |c| c.include Foo end describe :a do it "foo" do yielded = false bar do yielded = true end yielded.should be_true end end > >> >> >> On Aug 7, 4:09 pm, David Chelimsky wrote: >>> On Aug 7, 2010, at 8:23 AM, Kristian Mandrup wrote: >>> >>> >>> >>>> I simply want all methods of a module to be always available within >>>> the context of an Example group. >>> >>>> module RSpec >>>> module Generator >>>> def with_generator &block >>>> ... >>>> end >>> >>>> def setup_generator test_method_name=nil, &block >>>> ... >>>> end >>>> end >>>> end >>> >>>> How do I achieve this? >>> >>>> In RSpec 1 I think you would use ExampleGroupFactory >>> >>>> I thought I could do it something like this with RSpec 2? >>> >>>> RSpec.configure do |c| >>>> c.extend RSpec::Generator >>>> end >>> >>>> I want to be able to do something like this >>> >>>> before :each do >>> >>> before hooks are eval'd in the scope of an example, which is an _instance_ of the example group class. Try using include instead of extend: >>> >>> c.include RSpec::Generator >>> >>> HTH, >>> David >>> >>> >>> >>>> setup_generator 'migration_generator' do >>>> tests MigrationGenerator >>>> end >>>> end >>> >>>> it "should generate create_user migration" do >>>> with_generator do |g| >>>> ... >>>> end >>> >>>> Whereas now I have to do it like this, which I find a bit ugly and >>>> cumbersome >>> >>>> it "should generate create_user migration" do >>>> RSpec::Generator.with_generator do |g| >>>> name = 'create_users' >>>> end >>>> end >>> >>>> Thanks. >>>> _______________________________________________ >>>> rspec-users mailing list >>>> rspec-us... at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/rspec-users >>> >>> _______________________________________________ >>> rspec-users mailing list >>> rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users > From kmandrup.github at gmail.com Sat Aug 7 11:26:24 2010 From: kmandrup.github at gmail.com (Kristian Mandrup) Date: Sat, 7 Aug 2010 08:26:24 -0700 (PDT) Subject: [rspec-users] Release of RSpec for Generators 0.4.0 Message-ID: <92e99dc1-9d6c-4e3e-a9b8-fa0c6ffb918f@d8g2000yqf.googlegroups.com> Now with a full RSpec 2 test suite to demonstrate most of its features. Wiki to be updated with latest changes ASAP. http://github.com/kristianmandrup/rspec_for_generators This gem makes it very easy to spec that your generator generates files as expected and also lets you easily verify that the content of those files match what you expect - name of the class - subclass of class - class includes specific modules - contains certain instance or class methods ... In general it has a lot of nice matchers to match on generated Ruby source code (using regexp) It also has a nice DSL to spec generated migration files in detail (see below) # spec generated model file it "should decorate an existing Account model file with include Canable:Ables" do with_generator do |g| name = 'account' create_model name g.run_generator [name] g.should generate_model name do |content| content.should have_class name do |klass| klass.should include_module 'Canable::Ables' end end end end # spec generated migration file g.should generate_migration name do |content| content.should have_migration name do |klass| klass.should have_up do |up| up.should have_create_table :users do |user_tbl| user_tbl.should have_columns :name => :string, :age => :string end end klass.should have_down do |up| up.should have_drop_table :users end end end # spec generated Active Record observer g.run_generator [name] g.should generate_observer name do |content| content.should have_observer_class name do |klass| klass.should have_method :observe_me end end and many more... From dchelimsky at gmail.com Sat Aug 7 17:10:03 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 7 Aug 2010 16:10:03 -0500 Subject: [rspec-users] Name collision - how would you handle this? Message-ID: <958F356A-6B8F-49FF-B89E-C4557E943B2E@gmail.com> Hey all, It turns out that if you have * Rails (2 or 3) * Ruby-1.9 * a model named Message * let(:message) or def message in an example group * a Rails assertion in an example in that group * note that rspec-rails' matchers delegate to Rails' assertions You'll get an error saying "wrong number of arguments (1 for 0)" This is because the rails assertion, which, when running with Ruby-1.9, delegates to Minitest::Assertions#assert_block, which delegates to a message() method that it defines. So the message() method defined by let() overrides the message() method in the Assertions module, and results in unexpected and undesirable outcomes. So - what should we do? I don't think changing Minitest is really an option, as too many assertion libraries already wrap Minitest assertions. I don't think RSpec should be in the business of monitoring methods end-users define to make sure they're not overriding pre-existing methods (what if you override a method intentionally?). The only thing I'm left with is document this particular case and hope for the best, but that feels unsatisfactory as well. Recommendations? Words of wisdom? Cheers, David From ashley.moran at patchspace.co.uk Sat Aug 7 17:37:50 2010 From: ashley.moran at patchspace.co.uk (Ashley Moran) Date: Sat, 7 Aug 2010 22:37:50 +0100 Subject: [rspec-users] Name collision - how would you handle this? In-Reply-To: <958F356A-6B8F-49FF-B89E-C4557E943B2E@gmail.com> References: <958F356A-6B8F-49FF-B89E-C4557E943B2E@gmail.com> Message-ID: <11F9F3D8-71AC-4C9A-AE37-D48AD00420E4@patchspace.co.uk> On 7 Aug 2010, at 22:10, David Chelimsky wrote: > So - what should we do? I don't think changing Minitest is really an option, as too many assertion libraries already wrap Minitest assertions. I don't think RSpec should be in the business of monitoring methods end-users define to make sure they're not overriding pre-existing methods (what if you override a method intentionally?). The only thing I'm left with is document this particular case and hope for the best, but that feels unsatisfactory as well. While I fully agree if you `def` a method that already exists, you should be expected to deal with it yourself (that's just the way things are in Ruby), does the same apply to `let`? I can actually see an argument that you should only be able to `let` a method that doesn't already exist, and also only do it once (which is just a consequence of not being able to override a method, given the current implementation). Can you think of any downsides of preventing RSpec users from overriding existing methods with `let`? Are there any popular names already taken? Or other problems? To me, `let` is magic. I don't think of it, first and foremost, of defining a method. I see the things it creates as more like local variables, and just remind myself that they're methods if I wonder why it works. I'm not sold either way on this, but I think it's one worth a debate. Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran From ashley.moran at patchspace.co.uk Sat Aug 7 17:54:13 2010 From: ashley.moran at patchspace.co.uk (Ashley Moran) Date: Sat, 7 Aug 2010 22:54:13 +0100 Subject: [rspec-users] RSpec 2 autotest file Message-ID: <677927AF-1A58-446C-AE23-E01A306B1673@patchspace.co.uk> Hi I've tried using the autotest file from RSpec 2 (lib/autotest/rspec2.rb) but I've found a problem with it, that I think is a bug. The file contains two sections * an Autotest `Autotest.add_hook :initialize` block * an Autotest class "Autotest::Rspec2" In one project I'm working on, the code in Autotest::Rspec2 is really useful to me, but the :initialize hook contains setup that interferes with my project structure (I don't want a "lib" folder. Unfortunately, it appears that Autotest's `clear_mappings` can't stop the :initialize mappings making it into the final setup. This means that to use Autotest::Rspec2, I've had to copy-paste the contents into my own autotest file, rather than subclassing. Is this a bug? (ie, is there no workaround for the coupling between the two blocks?) If so, can it be fixed? Alternatively (or as well), is it time to drop autotest and use watchr instead? I noticed RSpec 2 uses that, and it seems really fast and simple, both of which go down very well with me... Any thoughts? Cheers Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran From dchelimsky at gmail.com Sat Aug 7 18:18:13 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 7 Aug 2010 17:18:13 -0500 Subject: [rspec-users] Name collision - how would you handle this? In-Reply-To: <11F9F3D8-71AC-4C9A-AE37-D48AD00420E4@patchspace.co.uk> References: <958F356A-6B8F-49FF-B89E-C4557E943B2E@gmail.com> <11F9F3D8-71AC-4C9A-AE37-D48AD00420E4@patchspace.co.uk> Message-ID: <2C5CCFC4-8F42-4200-89BE-3983E194D460@gmail.com> On Aug 7, 2010, at 4:37 PM, Ashley Moran wrote: > On 7 Aug 2010, at 22:10, David Chelimsky wrote: > >> So - what should we do? I don't think changing Minitest is really an option, as too many assertion libraries already wrap Minitest assertions. I don't think RSpec should be in the business of monitoring methods end-users define to make sure they're not overriding pre-existing methods (what if you override a method intentionally?). The only thing I'm left with is document this particular case and hope for the best, but that feels unsatisfactory as well. > > While I fully agree if you `def` a method that already exists, you should be expected to deal with it yourself (that's just the way things are in Ruby), does the same apply to `let`? I can actually see an argument that you should only be able to `let` a method that doesn't already exist, and also only do it once (which is just a consequence of not being able to override a method, given the current implementation). > Can you think of any downsides of preventing RSpec users from overriding existing methods with `let`? Yes. Let's say I write a shared example group with this: def foo raise "you need to define a foo method in the block passed to it_should_behave_like" end And you override it using let(:foo), which would be a perfectly reasonable way to handle it. In fact, it would be the way I would handle in instinctively, because now I don't have to wrote my own memoization handling into the method. > Are there any popular names already taken? Or other problems? > > To me, `let` is magic. I don't think of it, first and foremost, of defining a method. From the RDoc: Generates a method whose return value is memoized after the first call. > I see the things it creates as more like local variables, and just remind myself that they're methods if I wonder why it works. > > I'm not sold either way on this, but I think it's one worth a debate. The debate is on! Any other opinions out there? > Ash From ashley.moran at patchspace.co.uk Sat Aug 7 18:28:53 2010 From: ashley.moran at patchspace.co.uk (Ashley Moran) Date: Sat, 7 Aug 2010 23:28:53 +0100 Subject: [rspec-users] Recognising RSpec files in the Textmate bundle Message-ID: <8AC70538-323C-4DF6-9F67-64783028922C@patchspace.co.uk> Hi Did the RSpec TMBundle ever have multiple ways of recognising RSpec files? I'm convinced it user to look for "spec_helper" on the first line. The Ruby bundle does something similar, as it looks for "firstLineMatch = '^#!/.*\bruby';" The reason I ask is because I now have several files that end "_contract.rb". Conceivably I might have other shared example files with different suffices. But it's fairly safe to say they will all start with "require 'spec_helper'". WDYT? Cheers Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran From dchelimsky at gmail.com Sat Aug 7 18:44:33 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 7 Aug 2010 17:44:33 -0500 Subject: [rspec-users] Recognising RSpec files in the Textmate bundle In-Reply-To: <8AC70538-323C-4DF6-9F67-64783028922C@patchspace.co.uk> References: <8AC70538-323C-4DF6-9F67-64783028922C@patchspace.co.uk> Message-ID: On Aug 7, 2010, at 5:28 PM, Ashley Moran wrote: > Hi > > Did the RSpec TMBundle ever have multiple ways of recognising RSpec files? I'm convinced it user to look for "spec_helper" on the first line. I'm pretty sure it never did that. > The Ruby bundle does something similar, as it looks for "firstLineMatch = '^#!/.*\bruby';" > > The reason I ask is because I now have several files that end "_contract.rb". Conceivably I might have other shared example files with different suffices. But it's fairly safe to say they will all start with "require 'spec_helper'". I can't think of a case in which I've required spec_helper from a file that defines shared groups. So in my case, that is not safe to say :) > WDYT? I think it's good to do things that help end users, but we'd need a more reliable convention to base this on. Anybody (including Ashley) got any other suggestions? Cheers, David > Cheers > Ash > > -- > http://www.patchspace.co.uk/ > http://www.linkedin.com/in/ashleymoran > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users From dchelimsky at gmail.com Sat Aug 7 19:00:23 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 7 Aug 2010 18:00:23 -0500 Subject: [rspec-users] RSpec 2 autotest file In-Reply-To: <677927AF-1A58-446C-AE23-E01A306B1673@patchspace.co.uk> References: <677927AF-1A58-446C-AE23-E01A306B1673@patchspace.co.uk> Message-ID: On Aug 7, 2010, at 4:54 PM, Ashley Moran wrote: > Hi > > I've tried using the autotest file from RSpec 2 (lib/autotest/rspec2.rb) but I've found a problem with it, that I think is a bug. > > The file contains two sections > > * an Autotest `Autotest.add_hook :initialize` block > * an Autotest class "Autotest::Rspec2" > > In one project I'm working on, the code in Autotest::Rspec2 is really useful to me, but the :initialize hook contains setup that interferes with my project structure (I don't want a "lib" folder. > > Unfortunately, it appears that Autotest's `clear_mappings` can't stop the :initialize mappings making it into the final setup. This means that to use Autotest::Rspec2, I've had to copy-paste the contents into my own autotest file, rather than subclassing. > > Is this a bug? Yes. > (ie, is there no workaround for the coupling between the two blocks?) If so, can it be fixed? Yes: http://github.com/rspec/rspec-core/commit/c2e8a3947321e501b84113c1b2b1049df4868f4b > Alternatively (or as well), is it time to drop autotest and use watchr instead? I noticed RSpec 2 uses that, and it seems really fast and simple, both of which go down very well with me... I don't think we need to drop one to use the other :) Cheers, David > Any thoughts? > > Cheers > Ash > > -- > http://www.patchspace.co.uk/ > http://www.linkedin.com/in/ashleymoran > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users From phillipkoebbe at gmail.com Sat Aug 7 21:17:36 2010 From: phillipkoebbe at gmail.com (Phillip Koebbe) Date: Sat, 07 Aug 2010 20:17:36 -0500 Subject: [rspec-users] Recognising RSpec files in the Textmate bundle In-Reply-To: References: <8AC70538-323C-4DF6-9F67-64783028922C@patchspace.co.uk> Message-ID: <4C5E05B0.2060600@gmail.com> On 2010-08-07 5:44 PM, David Chelimsky wrote: > On Aug 7, 2010, at 5:28 PM, Ashley Moran wrote: > >> Hi >> >> Did the RSpec TMBundle ever have multiple ways of recognising RSpec files? I'm convinced it user to look for "spec_helper" on the first line. > I'm pretty sure it never did that. > >> The Ruby bundle does something similar, as it looks for "firstLineMatch = '^#!/.*\bruby';" >> >> The reason I ask is because I now have several files that end "_contract.rb". Conceivably I might have other shared example files with different suffices. But it's fairly safe to say they will all start with "require 'spec_helper'". > I can't think of a case in which I've required spec_helper from a file that defines shared groups. So in my case, that is not safe to say :) I have developed a system in which I require model_helper.rb in model specs, controller_helper.rb in controllers, and (you guessed it!) view_helper.rb in view specs. Each of those then require spec_helper.rb. I did this because I wanted fine-grained control over what gets loaded when, which started when I decided I wanted to use Remarkable for model specs only and didn't want it available during other specs. Plus, I keep customizations out of spec_helper.rb, which is a very good thing. >> WDYT? > I think it's good to do things that help end users, but we'd need a more reliable convention to base this on. Anybody (including Ashley) got any other suggestions? This is probably like trying to swat a fly with Mack truck, but what if all files under spec/ were considered RSpec files? Or possibly some variation of that? Peace, Phillip From ashley.moran at patchspace.co.uk Sun Aug 8 07:01:09 2010 From: ashley.moran at patchspace.co.uk (Ashley Moran) Date: Sun, 8 Aug 2010 12:01:09 +0100 Subject: [rspec-users] RSpec 2 autotest file In-Reply-To: References: <677927AF-1A58-446C-AE23-E01A306B1673@patchspace.co.uk> Message-ID: <85157754-414C-4486-9606-2C02E5D46FBF@patchspace.co.uk> On Aug 08, 2010, at 12:00 am, David Chelimsky wrote: > Yes: http://github.com/rspec/rspec-core/commit/c2e8a3947321e501b84113c1b2b1049df4868f4b Cool, ta :) I'll update my code shortly. Cheers Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran From matt at mattwynne.net Sun Aug 8 07:05:48 2010 From: matt at mattwynne.net (Matt Wynne) Date: Sun, 8 Aug 2010 12:05:48 +0100 Subject: [rspec-users] Name collision - how would you handle this? In-Reply-To: <2C5CCFC4-8F42-4200-89BE-3983E194D460@gmail.com> References: <958F356A-6B8F-49FF-B89E-C4557E943B2E@gmail.com> <11F9F3D8-71AC-4C9A-AE37-D48AD00420E4@patchspace.co.uk> <2C5CCFC4-8F42-4200-89BE-3983E194D460@gmail.com> Message-ID: On 7 Aug 2010, at 23:18, David Chelimsky wrote: > On Aug 7, 2010, at 4:37 PM, Ashley Moran wrote: > >> On 7 Aug 2010, at 22:10, David Chelimsky wrote: >> >>> So - what should we do? I don't think changing Minitest is really an option, as too many assertion libraries already wrap Minitest assertions. I don't think RSpec should be in the business of monitoring methods end-users define to make sure they're not overriding pre-existing methods (what if you override a method intentionally?). The only thing I'm left with is document this particular case and hope for the best, but that feels unsatisfactory as well. >> >> While I fully agree if you `def` a method that already exists, you should be expected to deal with it yourself (that's just the way things are in Ruby), does the same apply to `let`? I can actually see an argument that you should only be able to `let` a method that doesn't already exist, and also only do it once (which is just a consequence of not being able to override a method, given the current implementation). > >> Can you think of any downsides of preventing RSpec users from overriding existing methods with `let`? > > Yes. Let's say I write a shared example group with this: > > def foo > raise "you need to define a foo method in the block passed to it_should_behave_like" > end > > And you override it using let(:foo), which would be a perfectly reasonable way to handle it. In fact, it would be the way I would handle in instinctively, because now I don't have to wrote my own memoization handling into the method. I instinctively agree with ashley, but I see your point too David. Would it be awful to make let even more magic, and do something with #caller to forward the message to MiniTest if it didn't come from the code in your example block? Maybe the method defined by let could even have a __hidden name, and then RSpec can forward the message to that __hidden method if the message was sent from within the example block. Sounds pretty horrible, doesn't it? > >> Are there any popular names already taken? Or other problems? >> >> To me, `let` is magic. I don't think of it, first and foremost, of defining a method. > >> From the RDoc: Generates a method whose return value is memoized after the first call. > >> I see the things it creates as more like local variables, and just remind myself that they're methods if I wonder why it works. >> >> I'm not sold either way on this, but I think it's one worth a debate. > > The debate is on! Any other opinions out there? > >> Ash > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users cheers, Matt http://blog.mattwynne.net +44(0)7974 430184 From ashley.moran at patchspace.co.uk Sun Aug 8 07:11:53 2010 From: ashley.moran at patchspace.co.uk (Ashley Moran) Date: Sun, 8 Aug 2010 12:11:53 +0100 Subject: [rspec-users] Recognising RSpec files in the Textmate bundle In-Reply-To: <4C5E05B0.2060600@gmail.com> References: <8AC70538-323C-4DF6-9F67-64783028922C@patchspace.co.uk> <4C5E05B0.2060600@gmail.com> Message-ID: <9085C71F-DE9C-433B-AE66-8F471BE2C183@patchspace.co.uk> On Aug 08, 2010, at 2:17 am, Phillip Koebbe wrote: > I have developed a system in which I require model_helper.rb in model specs, controller_helper.rb in controllers, and (you guessed it!) view_helper.rb in view specs. Each of those then require spec_helper.rb. I did this because I wanted fine-grained control over what gets loaded when, which started when I decided I wanted to use Remarkable for model specs only and didn't want it available during other specs. Plus, I keep customizations out of spec_helper.rb, which is a very good thing. I think the way I worded by question may have made it sound like I was expecting everyone using TextMate to use put "require 'spec_helper'" at the top of the file... I didn't mean that! I was just suggesting that if a file starts with that require, then TextMate should see it as an RSpec file. As you've pointed out, this won't get all files, like your custom helpers. But I imagine it'd get a fairly high proportion. > This is probably like trying to swat a fly with Mack truck, but what if all files under spec/ were considered RSpec files? Or possibly some variation of that? I just double checked, and spec_helper.rb isn't considered an RSpec file - and actually, I don't think it should be. Also, I have a spec/support folder in most projects, with matchers etc. They aren't RSpec files either. So this route would probably give a lot of false positives. It might work better if this was the default folder structure: spec/ examples/ spec_helper.rb support/ Then you could glob everything under "examples". I actually do this with Cucumber, where my folder structure is: features/ descriptions/ step_definitions/ support/ But apparently I'm alone in the world not wanting to mix .feature files in with the support folder! Either way, I'm not convinced using the folder structure is the best solution. It forces TextMate users to structure there project a certain way. If you wanted a rails app like this: acceptance/ app/ integration/ spec/ (or whatever) then path matching wouldn't work. On Aug 07, 2010, at 11:44 pm, David Chelimsky wrote: > I think it's good to do things that help end users, but we'd need a more reliable convention to base this on. Anybody (including Ashley) got any other suggestions? Actually, I'm stuck :-/ I didn't think it'd be hard to identify RSpec example group files! I'm not much of a TextMate developer though. Anyone else got ideas? Cheers Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran From ashley.moran at patchspace.co.uk Sun Aug 8 09:05:44 2010 From: ashley.moran at patchspace.co.uk (Ashley Moran) Date: Sun, 8 Aug 2010 14:05:44 +0100 Subject: [rspec-users] Name collision - how would you handle this? In-Reply-To: References: <958F356A-6B8F-49FF-B89E-C4557E943B2E@gmail.com> <11F9F3D8-71AC-4C9A-AE37-D48AD00420E4@patchspace.co.uk> <2C5CCFC4-8F42-4200-89BE-3983E194D460@gmail.com> Message-ID: <6931E028-6788-4DA6-821A-639327C3382B@patchspace.co.uk> On 8 Aug 2010, at 12:05, Matt Wynne wrote: >> And you override it using let(:foo), which would be a perfectly reasonable way to handle it. In fact, it would be the way I would handle in instinctively, because now I don't have to wrote my own memoization handling into the method. > > I instinctively agree with ashley, but I see your point too David. > > Would it be awful to make let even more magic, and do something with #caller to forward the message to MiniTest if it didn't come from the code in your example block? Maybe the method defined by let could even have a __hidden name, and then RSpec can forward the message to that __hidden method if the message was sent from within the example block. > > Sounds pretty horrible, doesn't it? Hmmm, sounds like it could create a pretty nasty coupling to MiniTest. Maybe there's a general solution like: define_example_method do # or maybe "define_helper" ? # some stuff that only gets called from examples end I'm not sure I'd be keen on let embedding this magic, but maybe as a general concept it makes more sense, as a way of isolating helper code in example groups. There's another side to the debate, which is that in shared example groups, I prefer the precondition-check style to the templatemethod-fail style, ie rather than: def foo raise "you need to define a foo method ..." end I'd prefer to write: unless respond_to?(:foo) raise "you need to define a foo method ..." end But that would involve evaluating the configuration block first >:) Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran From rick.denatale at gmail.com Sun Aug 8 10:08:27 2010 From: rick.denatale at gmail.com (Rick DeNatale) Date: Sun, 8 Aug 2010 10:08:27 -0400 Subject: [rspec-users] Recognising RSpec files in the Textmate bundle In-Reply-To: <9085C71F-DE9C-433B-AE66-8F471BE2C183@patchspace.co.uk> References: <8AC70538-323C-4DF6-9F67-64783028922C@patchspace.co.uk> <4C5E05B0.2060600@gmail.com> <9085C71F-DE9C-433B-AE66-8F471BE2C183@patchspace.co.uk> Message-ID: On Sun, Aug 8, 2010 at 7:11 AM, Ashley Moran wrote: > I just double checked, and spec_helper.rb isn't considered an RSpec file - and actually, I don't think it should be. ?Also, I have a spec/support folder in most projects, with matchers etc. ?They aren't RSpec files either. ?So this route would probably give a lot of false positives. Textmate only looks at the first line for patterns in a language definition, typically that's used to find the shebang line. I think we want Textmate to use the Ruby language grammar for rspec files for indentation, delimiter matching etc. and the cost of having a separate language definition in the RSpec bundle in terms of confusion and or maintenance probably isn't worth it. For more about how textmate detects file times see: http://blog.macromates.com/2007/file-type-detection-rspec-rails/ -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Github: http://github.com/rubyredrick Twitter: @RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale From dchelimsky at gmail.com Sun Aug 8 11:27:53 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 8 Aug 2010 10:27:53 -0500 Subject: [rspec-users] Name collision - how would you handle this? In-Reply-To: <6931E028-6788-4DA6-821A-639327C3382B@patchspace.co.uk> References: <958F356A-6B8F-49FF-B89E-C4557E943B2E@gmail.com> <11F9F3D8-71AC-4C9A-AE37-D48AD00420E4@patchspace.co.uk> <2C5CCFC4-8F42-4200-89BE-3983E194D460@gmail.com> <6931E028-6788-4DA6-821A-639327C3382B@patchspace.co.uk> Message-ID: On Aug 8, 2010, at 8:05 AM, Ashley Moran wrote: > On 8 Aug 2010, at 12:05, Matt Wynne wrote: > >>> And you override it using let(:foo), which would be a perfectly reasonable way to handle it. In fact, it would be the way I would handle in instinctively, because now I don't have to wrote my own memoization handling into the method. >> >> I instinctively agree with ashley, but I see your point too David. >> >> Would it be awful to make let even more magic, and do something with #caller to forward the message to MiniTest if it didn't come from the code in your example block? Maybe the method defined by let could even have a __hidden name, and then RSpec can forward the message to that __hidden method if the message was sent from within the example block. >> >> Sounds pretty horrible, doesn't it? Yes! It seems crazy to me to put this burden on RSpec, or any downstream library. The problem here stems from the fact that Minitest consumed a non-testing-domain-specific name here. Test::Unit uses build_message, which is still sort of generic, but at least it's a verb. I submitted a request to change message to build_message [1], but even if Ryan agrees to do it, we wouldn't likely see it in ruby-1.9.2, so we'd still have the conflict for some time. Also, let's say he does agree - now people who like to prefix their test-data-building-helper-methods with build_xxx will be screwed too :) I wonder if the right answer is for RSpec to implement its own base assertion library, matching the Test::Unit/Minitest assertion APIs. That would have an interesting side effect in that domain-specific assertion-libraries could be used in RSpec without having to depend on Test::Unit or Minitest. It would also allow folks who like RSpec's structure (example groups and examples) but prefer assert_xxx over RSpec's matcher to use RSpec the way they'd like without the additional dependency. Thoughts on this? Really just an idea. I'm fairly convinced it's a bad one, but my head is sort of spinning over this issue right now (or maybe it's the cocktails at http://thedrchicago.com/), so I figured I'd throw it against the wall and see if it sticks (think spaghetti, or Jackson Pollock). > Hmmm, sounds like it could create a pretty nasty coupling to MiniTest. Maybe there's a general solution like: > > define_example_method do # or maybe "define_helper" ? > # some stuff that only gets called from examples > end > > I'm not sure I'd be keen on let embedding this magic, but maybe as a general concept it makes more sense, as a way of isolating helper code in example groups. This suggests, to me, "don't use Ruby if you want things to work right." > There's another side to the debate, which is that in shared example groups, I prefer the precondition-check style to the templatemethod-fail style, ie rather than: > > def foo > raise "you need to define a foo method ..." > end > > I'd prefer to write: > > unless respond_to?(:foo) > raise "you need to define a foo method ..." > end > > But that would involve evaluating the configuration block first >:) Keep in mind that it_should_behave_like generates a nested group, so shared group authors _can_ do this: shared_examples_for "bar" do unless respond_to?(:foo) raise "gotta have foo" end end and host group authors can do this: describe "thing" do let(:foo) { Foo.new } it_should_behave_like "bar" end That's part of the beauty of eval'ing the conditions block last - we get the best of both worlds. Cheers, David [1] http://rubyforge.org/tracker/index.php?func=detail&aid=28457&group_id=1040&atid=4097 > > Ash > > -- > http://www.patchspace.co.uk/ > http://www.linkedin.com/in/ashleymoran From dchelimsky at gmail.com Sun Aug 8 11:38:13 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 8 Aug 2010 10:38:13 -0500 Subject: [rspec-users] Name collision - how would you handle this? In-Reply-To: <958F356A-6B8F-49FF-B89E-C4557E943B2E@gmail.com> References: <958F356A-6B8F-49FF-B89E-C4557E943B2E@gmail.com> Message-ID: On Aug 7, 2010, at 4:10 PM, David Chelimsky wrote: > Hey all, > > It turns out that if you have > > * Rails (2 or 3) > * Ruby-1.9 > * a model named Message > * let(:message) or def message in an example group > * a Rails assertion in an example in that group > * note that rspec-rails' matchers delegate to Rails' assertions > > You'll get an error saying "wrong number of arguments (1 for 0)" > > This is because the rails assertion, which, when running with Ruby-1.9, delegates to Minitest::Assertions#assert_block, which delegates to a message() method that it defines. So the message() method defined by let() overrides the message() method in the Assertions module, and results in unexpected and undesirable outcomes. > > So - what should we do? I don't think changing Minitest is really an option, as too many assertion libraries already wrap Minitest assertions. I don't think RSpec should be in the business of monitoring methods end-users define to make sure they're not overriding pre-existing methods (what if you override a method intentionally?). The only thing I'm left with is document this particular case and hope for the best, but that feels unsatisfactory as well. > > Recommendations? Words of wisdom? FYI - here's the issue that spawned this thread: http://github.com/rspec/rspec-rails/issues/152 From matt at mattwynne.net Sun Aug 8 11:40:43 2010 From: matt at mattwynne.net (Matt Wynne) Date: Sun, 8 Aug 2010 16:40:43 +0100 Subject: [rspec-users] Name collision - how would you handle this? In-Reply-To: References: <958F356A-6B8F-49FF-B89E-C4557E943B2E@gmail.com> Message-ID: <13E563D1-9C62-4C75-A825-7D57F8C166DE@mattwynne.net> On 8 Aug 2010, at 16:38, David Chelimsky wrote: > On Aug 7, 2010, at 4:10 PM, David Chelimsky wrote: > >> Hey all, >> >> It turns out that if you have >> >> * Rails (2 or 3) >> * Ruby-1.9 >> * a model named Message >> * let(:message) or def message in an example group >> * a Rails assertion in an example in that group >> * note that rspec-rails' matchers delegate to Rails' assertions >> >> You'll get an error saying "wrong number of arguments (1 for 0)" >> >> This is because the rails assertion, which, when running with Ruby-1.9, delegates to Minitest::Assertions#assert_block, which delegates to a message() method that it defines. So the message() method defined by let() overrides the message() method in the Assertions module, and results in unexpected and undesirable outcomes. >> >> So - what should we do? I don't think changing Minitest is really an option, as too many assertion libraries already wrap Minitest assertions. I don't think RSpec should be in the business of monitoring methods end-users define to make sure they're not overriding pre-existing methods (what if you override a method intentionally?). The only thing I'm left with is document this particular case and hope for the best, but that feels unsatisfactory as well. >> >> Recommendations? Words of wisdom? > > FYI - here's the issue that spawned this thread: http://github.com/rspec/rspec-rails/issues/152 Can you use the Assertions module some other way than mixing it into the example (thereby polluting it with the Assertions module's methods?) > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users cheers, Matt http://blog.mattwynne.net +44(0)7974 430184 From dchelimsky at gmail.com Sun Aug 8 11:53:07 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 8 Aug 2010 10:53:07 -0500 Subject: [rspec-users] Name collision - how would you handle this? In-Reply-To: <13E563D1-9C62-4C75-A825-7D57F8C166DE@mattwynne.net> References: <958F356A-6B8F-49FF-B89E-C4557E943B2E@gmail.com> <13E563D1-9C62-4C75-A825-7D57F8C166DE@mattwynne.net> Message-ID: On Aug 8, 2010, at 10:40 AM, Matt Wynne wrote: > On 8 Aug 2010, at 16:38, David Chelimsky wrote: >> On Aug 7, 2010, at 4:10 PM, David Chelimsky wrote: >> >>> Hey all, >>> >>> It turns out that if you have >>> >>> * Rails (2 or 3) >>> * Ruby-1.9 >>> * a model named Message >>> * let(:message) or def message in an example group >>> * a Rails assertion in an example in that group >>> * note that rspec-rails' matchers delegate to Rails' assertions >>> >>> You'll get an error saying "wrong number of arguments (1 for 0)" >>> >>> This is because the rails assertion, which, when running with Ruby-1.9, delegates to Minitest::Assertions#assert_block, which delegates to a message() method that it defines. So the message() method defined by let() overrides the message() method in the Assertions module, and results in unexpected and undesirable outcomes. >>> >>> So - what should we do? I don't think changing Minitest is really an option, as too many assertion libraries already wrap Minitest assertions. I don't think RSpec should be in the business of monitoring methods end-users define to make sure they're not overriding pre-existing methods (what if you override a method intentionally?). The only thing I'm left with is document this particular case and hope for the best, but that feels unsatisfactory as well. >>> >>> Recommendations? Words of wisdom? >> >> FYI - here's the issue that spawned this thread: http://github.com/rspec/rspec-rails/issues/152 > > Can you use the Assertions module some other way than mixing it into the example (thereby polluting it with the Assertions module's methods?) I like the idea in the abstract, but most of the rails assertions rely on some state that is local to the example (@response, @controller, @request, etc, etc). RSpec _could_ gather up all those instance variables and pass them into an assertion-wrapper object, but then it would be highly coupled to that implementation and would lead us down a familiar and unfriendly path of forcing rspec-rails releases for every rails release. That's a world I hope to leave behind with Rails 3 :) It would also eliminate the option to use the Rails assertions directly in examples. Oh, well :) > cheers, > Matt > > http://blog.mattwynne.net > +44(0)7974 430184 From matt at mattwynne.net Sun Aug 8 12:13:18 2010 From: matt at mattwynne.net (Matt Wynne) Date: Sun, 8 Aug 2010 17:13:18 +0100 Subject: [rspec-users] Name collision - how would you handle this? In-Reply-To: References: <958F356A-6B8F-49FF-B89E-C4557E943B2E@gmail.com> <13E563D1-9C62-4C75-A825-7D57F8C166DE@mattwynne.net> Message-ID: <6972E490-0BCD-4225-A9B4-BFA06ECA972A@mattwynne.net> On 8 Aug 2010, at 16:53, David Chelimsky wrote: > On Aug 8, 2010, at 10:40 AM, Matt Wynne wrote: >> On 8 Aug 2010, at 16:38, David Chelimsky wrote: >>> On Aug 7, 2010, at 4:10 PM, David Chelimsky wrote: >>> >>>> Hey all, >>>> >>>> It turns out that if you have >>>> >>>> * Rails (2 or 3) >>>> * Ruby-1.9 >>>> * a model named Message >>>> * let(:message) or def message in an example group >>>> * a Rails assertion in an example in that group >>>> * note that rspec-rails' matchers delegate to Rails' assertions >>>> >>>> You'll get an error saying "wrong number of arguments (1 for 0)" >>>> >>>> This is because the rails assertion, which, when running with Ruby-1.9, delegates to Minitest::Assertions#assert_block, which delegates to a message() method that it defines. So the message() method defined by let() overrides the message() method in the Assertions module, and results in unexpected and undesirable outcomes. >>>> >>>> So - what should we do? I don't think changing Minitest is really an option, as too many assertion libraries already wrap Minitest assertions. I don't think RSpec should be in the business of monitoring methods end-users define to make sure they're not overriding pre-existing methods (what if you override a method intentionally?). The only thing I'm left with is document this particular case and hope for the best, but that feels unsatisfactory as well. >>>> >>>> Recommendations? Words of wisdom? >>> >>> FYI - here's the issue that spawned this thread: http://github.com/rspec/rspec-rails/issues/152 >> >> Can you use the Assertions module some other way than mixing it into the example (thereby polluting it with the Assertions module's methods?) > > I like the idea in the abstract, but most of the rails assertions rely on some state that is local to the example (@response, @controller, @request, etc, etc). RSpec _could_ gather up all those instance variables and pass them into an assertion-wrapper object, but then it would be highly coupled to that implementation and would lead us down a familiar and unfriendly path of forcing rspec-rails releases for every rails release. That's a world I hope to leave behind with Rails 3 :) So leave the rails assertions mixed into the example, but forward all the calls to the MiniTest::Assertions methods to some other object that has them mixed in. Won't that work? > > It would also eliminate the option to use the Rails assertions directly in examples. > > Oh, well :) > >> cheers, >> Matt >> >> http://blog.mattwynne.net >> +44(0)7974 430184 > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users cheers, Matt http://blog.mattwynne.net +44(0)7974 430184 From myron.marston at gmail.com Sun Aug 8 12:58:10 2010 From: myron.marston at gmail.com (Myron Marston) Date: Sun, 8 Aug 2010 09:58:10 -0700 (PDT) Subject: [rspec-users] Name collision - how would you handle this? In-Reply-To: <6972E490-0BCD-4225-A9B4-BFA06ECA972A@mattwynne.net> References: <958F356A-6B8F-49FF-B89E-C4557E943B2E@gmail.com> <13E563D1-9C62-4C75-A825-7D57F8C166DE@mattwynne.net> <6972E490-0BCD-4225-A9B4-BFA06ECA972A@mattwynne.net> Message-ID: Good error messages are important to a library's usability. Could we find away to give the user a good error message when they override a "reserved method"? I'm thinking this could be accomplished with 2 simple pieces: 1. A method_added hook in Rspec-core that gives a warning or error when a reserved method is overridden. 2. An API that allows libraries to add to the reserved methods list. That way, rspec doesn't have to have knowledge of other libraries; it would be the responsibility of other libraries to add their reserved methods to the list. Myron On Aug 8, 9:13?am, Matt Wynne wrote: > On 8 Aug 2010, at 16:53, David Chelimsky wrote: > > > > > > > On Aug 8, 2010, at 10:40 AM, Matt Wynne wrote: > >> On 8 Aug 2010, at 16:38, David Chelimsky wrote: > >>> On Aug 7, 2010, at 4:10 PM, David Chelimsky wrote: > > >>>> Hey all, > > >>>> It turns out that if you have > > >>>> * Rails (2 or 3) > >>>> * Ruby-1.9 > >>>> * a model named Message > >>>> * let(:message) or def message in an example group > >>>> * a Rails assertion in an example in that group > >>>> * note that rspec-rails' matchers delegate to Rails' assertions > > >>>> You'll get an error saying "wrong number of arguments (1 for 0)" > > >>>> This is because the rails assertion, which, when running with Ruby-1.9, delegates to Minitest::Assertions#assert_block, which delegates to a message() method that it defines. So the message() method defined by let() overrides the message() method in the Assertions module, and results in unexpected and undesirable outcomes. > > >>>> So - what should we do? I don't think changing Minitest is really an option, as too many assertion libraries already wrap Minitest assertions. I don't think RSpec should be in the business of monitoring methods end-users define to make sure they're not overriding pre-existing methods (what if you override a method intentionally?). The only thing I'm left with is document this particular case and hope for the best, but that feels unsatisfactory as well. > > >>>> Recommendations? Words of wisdom? > > >>> FYI - here's the issue that spawned this thread:http://github.com/rspec/rspec-rails/issues/152 > > >> Can you use the Assertions module some other way than mixing it into the example (thereby polluting it with the Assertions module's methods?) > > > I like the idea in the abstract, but most of the rails assertions rely on some state that is local to the example (@response, @controller, @request, etc, etc). RSpec _could_ gather up all those instance variables and pass them into an assertion-wrapper object, but then it would be highly coupled to that implementation and would lead us down a familiar and unfriendly path of forcing rspec-rails releases for every rails release. That's a world I hope to leave behind with Rails 3 :) > > So leave the rails assertions mixed into the example, but forward all the calls to the MiniTest::Assertions methods to some other object that has them mixed in. Won't that work? > > > > > It would also eliminate the option to use the Rails assertions directly in examples. > > > Oh, well :) > > >> cheers, > >> Matt > > >>http://blog.mattwynne.net > >>+44(0)7974 430184 > > > _______________________________________________ > > rspec-users mailing list > > rspec-us... at rubyforge.org > >http://rubyforge.org/mailman/listinfo/rspec-users > > cheers, > Matt > > http://blog.mattwynne.net+44(0)7974 430184 > > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users From phillipkoebbe at gmail.com Sun Aug 8 16:53:05 2010 From: phillipkoebbe at gmail.com (Phillip Koebbe) Date: Sun, 08 Aug 2010 15:53:05 -0500 Subject: [rspec-users] Recognising RSpec files in the Textmate bundle In-Reply-To: <9085C71F-DE9C-433B-AE66-8F471BE2C183@patchspace.co.uk> References: <8AC70538-323C-4DF6-9F67-64783028922C@patchspace.co.uk> <4C5E05B0.2060600@gmail.com> <9085C71F-DE9C-433B-AE66-8F471BE2C183@patchspace.co.uk> Message-ID: <4C5F1931.6020604@gmail.com> On 2010-08-08 6:11 AM, Ashley Moran wrote: > On Aug 08, 2010, at 2:17 am, Phillip Koebbe wrote: > >> I have developed a system in which I require model_helper.rb in model specs, controller_helper.rb in controllers, and (you guessed it!) view_helper.rb in view specs. Each of those then require spec_helper.rb. I did this because I wanted fine-grained control over what gets loaded when, which started when I decided I wanted to use Remarkable for model specs only and didn't want it available during other specs. Plus, I keep customizations out of spec_helper.rb, which is a very good thing. > I think the way I worded by question may have made it sound like I was expecting everyone using TextMate to use put "require 'spec_helper'" at the top of the file... I didn't mean that! I was just suggesting that if a file starts with that require, then TextMate should see it as an RSpec file. As you've pointed out, this won't get all files, like your custom helpers. But I imagine it'd get a fairly high proportion. > Yes, I think I misunderstood what you were getting at. I would agree that the majority of RSpec users probably leave the "require 'spec_helper'" line at the beginning of their specs and therefore the vast majority of cases would be covered. Sadly (I guess...), I am, once again, an outlier. I can't think of a single example file that requires spec_helper. >> This is probably like trying to swat a fly with Mack truck, but what if all files under spec/ were considered RSpec files? Or possibly some variation of that? > I just double checked, and spec_helper.rb isn't considered an RSpec file - and actually, I don't think it should be. I guess I also misunderstood what you meant by "RSpec file". I assumed it to mean any file belonging to RSpec, but I guess what it really means is a file with examples in it? > Also, I have a spec/support folder in most projects, with matchers etc. They aren't RSpec files either. So this route would probably give a lot of false positives. > > It might work better if this was the default folder structure: > > spec/ > examples/ > spec_helper.rb > support/ > > Then you could glob everything under "examples". I actually do this with Cucumber, where my folder structure is: > > features/ > descriptions/ > step_definitions/ > support/ > > But apparently I'm alone in the world not wanting to mix .feature files in with the support folder! I don't think you are alone in your quest to achieve greater organization. I am guessing that in your suggested RSpec folder structure, the current folders of controllers|helpers|models|views would all live under examples? I might go for that. I think some (many?) might say that it's an unnecessary level, but I think I'd prefer that. I might even look into doing that anyway :) After all, my Cucumber folder structure is cuke/ features/ steps/ support/ And I use subfolders under features and steps just like I do in RSpec. > Either way, I'm not convinced using the folder structure is the best solution. It forces TextMate users to structure there project a certain way. If you wanted a rails app like this: > > acceptance/ > app/ > integration/ > spec/ > > (or whatever) then path matching wouldn't work. Right. I wouldn't want a particular structure to be forced upon me, so I'd rather not see that happen to anyone. > On Aug 07, 2010, at 11:44 pm, David Chelimsky wrote: > >> I think it's good to do things that help end users, but we'd need a more reliable convention to base this on. Anybody (including Ashley) got any other suggestions? > Actually, I'm stuck :-/ I didn't think it'd be hard to identify RSpec example group files! I'm not much of a TextMate developer though. Anyone else got ideas? > > Cheers > Ash > Here's another idea that's not so great, but maybe it will spur some thinking in someone else. What about a custom generator (or a flag on the official one) that added something like a shebang line at the beginning of example files. A short comment that identifies the file, like "# RSpec". Then a TM bundle could pick up on that and be happy. I don't know about vim or any other editor, though. Peace, Phillip From dchelimsky at gmail.com Sun Aug 8 20:54:55 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 8 Aug 2010 19:54:55 -0500 Subject: [rspec-users] Name collision - how would you handle this? In-Reply-To: <6972E490-0BCD-4225-A9B4-BFA06ECA972A@mattwynne.net> References: <958F356A-6B8F-49FF-B89E-C4557E943B2E@gmail.com> <13E563D1-9C62-4C75-A825-7D57F8C166DE@mattwynne.net> <6972E490-0BCD-4225-A9B4-BFA06ECA972A@mattwynne.net> Message-ID: On Aug 8, 2010, at 11:13 AM, Matt Wynne wrote: > > On 8 Aug 2010, at 16:53, David Chelimsky wrote: > >> On Aug 8, 2010, at 10:40 AM, Matt Wynne wrote: >>> On 8 Aug 2010, at 16:38, David Chelimsky wrote: >>>> On Aug 7, 2010, at 4:10 PM, David Chelimsky wrote: >>>> >>>>> Hey all, >>>>> >>>>> It turns out that if you have >>>>> >>>>> * Rails (2 or 3) >>>>> * Ruby-1.9 >>>>> * a model named Message >>>>> * let(:message) or def message in an example group >>>>> * a Rails assertion in an example in that group >>>>> * note that rspec-rails' matchers delegate to Rails' assertions >>>>> >>>>> You'll get an error saying "wrong number of arguments (1 for 0)" >>>>> >>>>> This is because the rails assertion, which, when running with Ruby-1.9, delegates to Minitest::Assertions#assert_block, which delegates to a message() method that it defines. So the message() method defined by let() overrides the message() method in the Assertions module, and results in unexpected and undesirable outcomes. >>>>> >>>>> So - what should we do? I don't think changing Minitest is really an option, as too many assertion libraries already wrap Minitest assertions. I don't think RSpec should be in the business of monitoring methods end-users define to make sure they're not overriding pre-existing methods (what if you override a method intentionally?). The only thing I'm left with is document this particular case and hope for the best, but that feels unsatisfactory as well. >>>>> >>>>> Recommendations? Words of wisdom? >>>> >>>> FYI - here's the issue that spawned this thread: http://github.com/rspec/rspec-rails/issues/152 >>> >>> Can you use the Assertions module some other way than mixing it into the example (thereby polluting it with the Assertions module's methods?) >> >> I like the idea in the abstract, but most of the rails assertions rely on some state that is local to the example (@response, @controller, @request, etc, etc). RSpec _could_ gather up all those instance variables and pass them into an assertion-wrapper object, but then it would be highly coupled to that implementation and would lead us down a familiar and unfriendly path of forcing rspec-rails releases for every rails release. That's a world I hope to leave behind with Rails 3 :) > > So leave the rails assertions mixed into the example, but forward all the calls to the MiniTest::Assertions methods to some other object that has them mixed in. Won't that work? Here's a prototype implementation: http://github.com/rspec/rspec-rails/commit/0cd384536cf532435ec8f290a9c357b60872acd7 It's on a branch (http://github.com/rspec/rspec-rails/tree/assertion-delegate) because I'm not convinced this is the right way to go yet, but I'd like some feedback from anyone who wishes to peruse and comment. Thanks, David >> It would also eliminate the option to use the Rails assertions directly in examples. >> >> Oh, well :) >> >>> cheers, >>> Matt >>> >>> http://blog.mattwynne.net >>> +44(0)7974 430184 >> >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users > > cheers, > Matt > > http://blog.mattwynne.net > +44(0)7974 430184 > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users From dchelimsky at gmail.com Sun Aug 8 21:29:48 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 8 Aug 2010 20:29:48 -0500 Subject: [rspec-users] Name collision - how would you handle this? In-Reply-To: References: <958F356A-6B8F-49FF-B89E-C4557E943B2E@gmail.com> <13E563D1-9C62-4C75-A825-7D57F8C166DE@mattwynne.net> <6972E490-0BCD-4225-A9B4-BFA06ECA972A@mattwynne.net> Message-ID: <3D0F0C84-8692-4346-A97C-CFC6AFEF5599@gmail.com> On Aug 8, 2010, at 11:58 AM, Myron Marston wrote: > Good error messages are important to a library's usability. Could we > find away to give the user a good error message when they override a > "reserved method"? > > I'm thinking this could be accomplished with 2 simple pieces: > > 1. A method_added hook in Rspec-core that gives a warning or error > when a reserved method is overridden. > 2. An API that allows libraries to add to the reserved methods list. > > That way, rspec doesn't have to have knowledge of other libraries; it > would be the responsibility of other libraries to add their reserved > methods to the list. Yehuda Katz made a similar suggestion to me, referencing some code from merb: http://github.com/merb/merb/blob/master/merb-core/lib/merb-core/controller/merb_controller.rb#L508 Merb also has an override! method that end users can use to override the registered reserved methods, which I agree would be a necessary part of this. The idea being that any user that does that does so explicitly and knowingly. The blacklist comment probably wouldn't work for upstream libs like Rails, Test::Unit or MiniUnit. It would be up to RSpec to define those lists. But maybe that's an acceptable tradeoff. WDYT? > Myron > > On Aug 8, 9:13 am, Matt Wynne wrote: >> On 8 Aug 2010, at 16:53, David Chelimsky wrote: >> >> >> >> >> >>> On Aug 8, 2010, at 10:40 AM, Matt Wynne wrote: >>>> On 8 Aug 2010, at 16:38, David Chelimsky wrote: >>>>> On Aug 7, 2010, at 4:10 PM, David Chelimsky wrote: >> >>>>>> Hey all, >> >>>>>> It turns out that if you have >> >>>>>> * Rails (2 or 3) >>>>>> * Ruby-1.9 >>>>>> * a model named Message >>>>>> * let(:message) or def message in an example group >>>>>> * a Rails assertion in an example in that group >>>>>> * note that rspec-rails' matchers delegate to Rails' assertions >> >>>>>> You'll get an error saying "wrong number of arguments (1 for 0)" >> >>>>>> This is because the rails assertion, which, when running with Ruby-1.9, delegates to Minitest::Assertions#assert_block, which delegates to a message() method that it defines. So the message() method defined by let() overrides the message() method in the Assertions module, and results in unexpected and undesirable outcomes. >> >>>>>> So - what should we do? I don't think changing Minitest is really an option, as too many assertion libraries already wrap Minitest assertions. I don't think RSpec should be in the business of monitoring methods end-users define to make sure they're not overriding pre-existing methods (what if you override a method intentionally?). The only thing I'm left with is document this particular case and hope for the best, but that feels unsatisfactory as well. >> >>>>>> Recommendations? Words of wisdom? >> >>>>> FYI - here's the issue that spawned this thread:http://github.com/rspec/rspec-rails/issues/152 >> >>>> Can you use the Assertions module some other way than mixing it into the example (thereby polluting it with the Assertions module's methods?) >> >>> I like the idea in the abstract, but most of the rails assertions rely on some state that is local to the example (@response, @controller, @request, etc, etc). RSpec _could_ gather up all those instance variables and pass them into an assertion-wrapper object, but then it would be highly coupled to that implementation and would lead us down a familiar and unfriendly path of forcing rspec-rails releases for every rails release. That's a world I hope to leave behind with Rails 3 :) >> >> So leave the rails assertions mixed into the example, but forward all the calls to the MiniTest::Assertions methods to some other object that has them mixed in. Won't that work? >> >> >> >>> It would also eliminate the option to use the Rails assertions directly in examples. >> >>> Oh, well :) >> >>>> cheers, >>>> Matt >> >>>> http://blog.mattwynne.net >>>> +44(0)7974 430184 >> >>> _______________________________________________ >>> rspec-users mailing list >>> rspec-us... at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rspec-users >> >> cheers, >> Matt >> >> http://blog.mattwynne.net+44(0)7974 430184 >> >> _______________________________________________ >> rspec-users mailing list >> rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users From elliot.winkler at gmail.com Sun Aug 8 23:45:00 2010 From: elliot.winkler at gmail.com (Elliot Winkler) Date: Sun, 8 Aug 2010 22:45:00 -0500 Subject: [rspec-users] Recognising RSpec files in the Textmate bundle In-Reply-To: <4C5F1931.6020604@gmail.com> References: <8AC70538-323C-4DF6-9F67-64783028922C@patchspace.co.uk> <4C5E05B0.2060600@gmail.com> <9085C71F-DE9C-433B-AE66-8F471BE2C183@patchspace.co.uk> <4C5F1931.6020604@gmail.com> Message-ID: On Sun, Aug 8, 2010 at 3:53 PM, Phillip Koebbe wrote: > Here's another idea that's not so great, but maybe it will spur some > thinking in someone else. What about a custom generator (or a flag on the > official one) that added something like a shebang line at the beginning of > example files. A short comment that identifies the file, like "# RSpec". > Then a TM bundle could pick up on that and be happy. > Putting aside the fact that this is solving a very specific problem.... what about #!/usr/bin/env spec ? 99% of the time the shebang won't be used, I'd wager, so it'd pretty much be harmless. -- Elliot -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoffer.klang at gmail.com Mon Aug 9 02:29:58 2010 From: christoffer.klang at gmail.com (christofferklang) Date: Sun, 8 Aug 2010 23:29:58 -0700 (PDT) Subject: [rspec-users] testing 404 redirects in the controller with rspec beta 19 Message-ID: <29385087.post@talk.nabble.com> Hello, I'm new to rails and I'm trying to wrap my heads around how to spec controllers using RSpec (using rails 3rc1 and rspec 2.0.0.beta.19). The problem I've run into is when I want to test that my controllers respond with a 404 for unfound records. Whenever I run the spec, the ActiveRecord::RecordNotFound exception is not caught by rails, causing the spec example to fail since the exception propagates out of the controller into the spec. >From googling around I get that rails only handles the exceptions and does a 404 response when it's run in production mode, and that you need to call rescue_action_in_public! in your example if you want this behavior for test mode. However, this does not seem to trigger rails into handling this with a redirect to 404 even though the @request.remote_addr gets set to 208.77.188.166. Do I need to set something up for rails to trigger 404 redirecting of RecordNotFound? Or is this not at all the correct way to test missing records? My full example: (using factory_girl, rspec mocks and devise) it "respons with 404 when trying to edit non-existing reads" do rescue_action_in_public! sign_in(@user) Read.should_receive(:find_by_id_and_user_id!).with(2, @user.id).and_raise(ActiveRecord::RecordNotFound) get :edit, :id => 2 response.status.should eql 404 end and the exception: 1) ReadsController resources respons with 404 for non existing reads for GET /reads/2/edit Failure/Error: get :edit, :id => 2 ActiveRecord::RecordNotFound Thanks, /Christoffer -- View this message in context: http://old.nabble.com/testing-404-redirects-in-the-controller-with-rspec-beta-19-tp29385087p29385087.html Sent from the rspec-users mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From phillipkoebbe at gmail.com Mon Aug 9 06:40:04 2010 From: phillipkoebbe at gmail.com (Phillip Koebbe) Date: Mon, 09 Aug 2010 05:40:04 -0500 Subject: [rspec-users] testing 404 redirects in the controller with rspec beta 19 In-Reply-To: <29385087.post@talk.nabble.com> References: <29385087.post@talk.nabble.com> Message-ID: <4C5FDB04.2080707@gmail.com> On 2010-08-09 1:29 AM, christofferklang wrote: > Hello, > > I'm new to rails and I'm trying to wrap my heads around how to spec > controllers using RSpec (using rails 3rc1 and rspec 2.0.0.beta.19). > > The problem I've run into is when I want to test that my controllers > respond with a 404 for unfound records. Whenever I run the spec, the > ActiveRecord::RecordNotFound exception is not caught by rails, causing > the spec example to fail since the exception propagates out of the > controller into the spec. > > >From googling around I get that rails only handles the exceptions and > does a 404 response when it's run in production mode, and that you > need to call |rescue_action_in_public!| in your example if you want > this behavior for test mode. However, this does not seem to trigger > rails into handling this with a redirect to 404 even though the > @request.remote_addr gets set to 208.77.188.166. > > Do I need to set something up for rails to trigger 404 redirecting of > RecordNotFound? Or is this not at all the correct way to test missing > records? > > My full example: (using factory_girl, rspec mocks and devise) > > it "respons with 404 when trying to edit non-existing reads" do > rescue_action_in_public! > sign_in(@user) > Read.should_receive(:find_by_id_and_user_id!).with(2, @user.id).and_raise(ActiveRecord::RecordNotFound) > > get :edit, :id => 2 > response.status.should eql 404 > end > > > and the exception: > 1) ReadsController resources respons with 404 for non existing reads for GET /reads/2/edit > Failure/Error: get :edit, :id => 2 > *ActiveRecord::RecordNotFound* > Thanks, /Christoffer This isn't RSpec 2 / Rails 3 specific, but here's how I've come to handle this situation: I wrote a small controller plugin (I call it IdSecurity) that looks for an id parameter on all requests and queries the database looking for the matching record. If one is found, it sets an instance variable using either the class name or a custom name passed in during configuration. If it is not found, it redirects to the target of your choice, mine being an error handling route to which I pass the specific error number I want it to use (in this case, 404). For testing, all I have to do is stub the Model.find_by_id call returning nil and check that the response redirects to my error route with the error number argument. It looks something like: controller: acts_as_id_security '/error/404' # I haven't managed to get it to use route helpers here :( def edit # @person will be set by IdSecurity automatically end controller spec: context 'record not found' do it 'should redirect to error path with 404' do Person.stub(:find_by_id).and_return(nil) get :edit, :id => '1' response.should redirect_to(error_path(404)) end end This allows me to test that the plugin works, use it it controllers, and forget it. I just have to remember that in every action that an id is expected, there will already be an instance variable set, but isn't a big deal to me. Peace, Phillip From christoffer.klang at gmail.com Mon Aug 9 07:31:35 2010 From: christoffer.klang at gmail.com (Christoffer Klang) Date: Mon, 9 Aug 2010 13:31:35 +0200 Subject: [rspec-users] testing 404 redirects in the controller with rspec beta 19 In-Reply-To: <4C5FDB04.2080707@gmail.com> References: <29385087.post@talk.nabble.com> <4C5FDB04.2080707@gmail.com> Message-ID: <133A03D3-BF0B-437A-8125-AE1041F5F9FE@gmail.com> Ah, that looks quite interesting. I'd prefer to let rails do the 404 error handling (adding more magic to the already overwhelming amount is to much for my brain at this point ;), but if I'll have to handle it myself this looks like a viable solution. Thanks, /Christoffer On Aug 9, 2010, at 12:40 PM, Phillip Koebbe wrote: > On 2010-08-09 1:29 AM, christofferklang wrote: >> Hello, >> >> I'm new to rails and I'm trying to wrap my heads around how to spec controllers using RSpec (using rails 3rc1 and rspec 2.0.0.beta.19). >> >> The problem I've run into is when I want to test that my controllers respond with a 404 for unfound records. Whenever I run the spec, the ActiveRecord::RecordNotFound exception is not caught by rails, causing the spec example to fail since the exception propagates out of the controller into the spec. >> >> >From googling around I get that rails only handles the exceptions and does a 404 response when it's run in production mode, and that you need to call |rescue_action_in_public!| in your example if you want this behavior for test mode. However, this does not seem to trigger rails into handling this with a redirect to 404 even though the @request.remote_addr gets set to 208.77.188.166. >> >> Do I need to set something up for rails to trigger 404 redirecting of RecordNotFound? Or is this not at all the correct way to test missing records? >> >> My full example: (using factory_girl, rspec mocks and devise) >> >> it "respons with 404 when trying to edit non-existing reads" do >> rescue_action_in_public! >> sign_in(@user) >> Read.should_receive(:find_by_id_and_user_id!).with(2, @user.id).and_raise(ActiveRecord::RecordNotFound) >> >> get :edit, :id => 2 >> response.status.should eql 404 >> end >> >> >> and the exception: >> 1) ReadsController resources respons with 404 for non existing reads for GET /reads/2/edit >> Failure/Error: get :edit, :id => 2 >> *ActiveRecord::RecordNotFound* >> Thanks, /Christoffer > > This isn't RSpec 2 / Rails 3 specific, but here's how I've come to handle this situation: > > I wrote a small controller plugin (I call it IdSecurity) that looks for an id parameter on all requests and queries the database looking for the matching record. If one is found, it sets an instance variable using either the class name or a custom name passed in during configuration. If it is not found, it redirects to the target of your choice, mine being an error handling route to which I pass the specific error number I want it to use (in this case, 404). For testing, all I have to do is stub the Model.find_by_id call returning nil and check that the response redirects to my error route with the error number argument. It looks something like: > > controller: > > acts_as_id_security '/error/404' # I haven't managed to get it to use route helpers here :( > > def edit > # @person will be set by IdSecurity automatically > end > > controller spec: > > context 'record not found' do > it 'should redirect to error path with 404' do > Person.stub(:find_by_id).and_return(nil) > get :edit, :id => '1' > response.should redirect_to(error_path(404)) > end > end > > This allows me to test that the plugin works, use it it controllers, and forget it. I just have to remember that in every action that an id is expected, there will already be an instance variable set, but isn't a big deal to me. > > Peace, > Phillip > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users From matt at mattwynne.net Mon Aug 9 07:37:06 2010 From: matt at mattwynne.net (Matt Wynne) Date: Mon, 9 Aug 2010 12:37:06 +0100 Subject: [rspec-users] Name collision - how would you handle this? In-Reply-To: References: <958F356A-6B8F-49FF-B89E-C4557E943B2E@gmail.com> <13E563D1-9C62-4C75-A825-7D57F8C166DE@mattwynne.net> <6972E490-0BCD-4225-A9B4-BFA06ECA972A@mattwynne.net> Message-ID: <86BA7B78-9FC9-4DDA-8C6E-79298F9E7ABD@mattwynne.net> On 9 Aug 2010, at 01:54, David Chelimsky wrote: > > On Aug 8, 2010, at 11:13 AM, Matt Wynne wrote: > >> >> On 8 Aug 2010, at 16:53, David Chelimsky wrote: >> >>> On Aug 8, 2010, at 10:40 AM, Matt Wynne wrote: >>>> On 8 Aug 2010, at 16:38, David Chelimsky wrote: >>>>> On Aug 7, 2010, at 4:10 PM, David Chelimsky wrote: >>>>> >>>>>> Hey all, >>>>>> >>>>>> It turns out that if you have >>>>>> >>>>>> * Rails (2 or 3) >>>>>> * Ruby-1.9 >>>>>> * a model named Message >>>>>> * let(:message) or def message in an example group >>>>>> * a Rails assertion in an example in that group >>>>>> * note that rspec-rails' matchers delegate to Rails' assertions >>>>>> >>>>>> You'll get an error saying "wrong number of arguments (1 for 0)" >>>>>> >>>>>> This is because the rails assertion, which, when running with Ruby-1.9, delegates to Minitest::Assertions#assert_block, which delegates to a message() method that it defines. So the message() method defined by let() overrides the message() method in the Assertions module, and results in unexpected and undesirable outcomes. >>>>>> >>>>>> So - what should we do? I don't think changing Minitest is really an option, as too many assertion libraries already wrap Minitest assertions. I don't think RSpec should be in the business of monitoring methods end-users define to make sure they're not overriding pre-existing methods (what if you override a method intentionally?). The only thing I'm left with is document this particular case and hope for the best, but that feels unsatisfactory as well. >>>>>> >>>>>> Recommendations? Words of wisdom? >>>>> >>>>> FYI - here's the issue that spawned this thread: http://github.com/rspec/rspec-rails/issues/152 >>>> >>>> Can you use the Assertions module some other way than mixing it into the example (thereby polluting it with the Assertions module's methods?) >>> >>> I like the idea in the abstract, but most of the rails assertions rely on some state that is local to the example (@response, @controller, @request, etc, etc). RSpec _could_ gather up all those instance variables and pass them into an assertion-wrapper object, but then it would be highly coupled to that implementation and would lead us down a familiar and unfriendly path of forcing rspec-rails releases for every rails release. That's a world I hope to leave behind with Rails 3 :) >> >> So leave the rails assertions mixed into the example, but forward all the calls to the MiniTest::Assertions methods to some other object that has them mixed in. Won't that work? > > Here's a prototype implementation: http://github.com/rspec/rspec-rails/commit/0cd384536cf532435ec8f290a9c357b60872acd7 > > It's on a branch (http://github.com/rspec/rspec-rails/tree/assertion-delegate) because I'm not convinced this is the right way to go yet, but I'd like some feedback from anyone who wishes to peruse and comment. Yeah, that's what I was talking about. Couple of thoughts / questions: I'm still not clear why you need to copy the instance variable over though - do the rails assertions get monkey-patched into the Test::Unit::Assertions module then? Also, how come there's nothing in the specs about the #message method that caused all this? > > Thanks, > David > >>> It would also eliminate the option to use the Rails assertions directly in examples. >>> >>> Oh, well :) >>> >>>> cheers, >>>> Matt >>>> >>>> http://blog.mattwynne.net >>>> +44(0)7974 430184 >>> >>> _______________________________________________ >>> rspec-users mailing list >>> rspec-users at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rspec-users >> >> cheers, >> Matt >> >> http://blog.mattwynne.net >> +44(0)7974 430184 >> >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users cheers, Matt http://blog.mattwynne.net +44(0)7974 430184 From dchelimsky at gmail.com Mon Aug 9 08:04:59 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 9 Aug 2010 07:04:59 -0500 Subject: [rspec-users] Name collision - how would you handle this? In-Reply-To: <86BA7B78-9FC9-4DDA-8C6E-79298F9E7ABD@mattwynne.net> References: <958F356A-6B8F-49FF-B89E-C4557E943B2E@gmail.com> <13E563D1-9C62-4C75-A825-7D57F8C166DE@mattwynne.net> <6972E490-0BCD-4225-A9B4-BFA06ECA972A@mattwynne.net> <86BA7B78-9FC9-4DDA-8C6E-79298F9E7ABD@mattwynne.net> Message-ID: On Aug 9, 2010, at 6:37 AM, Matt Wynne wrote: > > On 9 Aug 2010, at 01:54, David Chelimsky wrote: > >> >> On Aug 8, 2010, at 11:13 AM, Matt Wynne wrote: >> >>> >>> On 8 Aug 2010, at 16:53, David Chelimsky wrote: >>> >>>> On Aug 8, 2010, at 10:40 AM, Matt Wynne wrote: >>>>> On 8 Aug 2010, at 16:38, David Chelimsky wrote: >>>>>> On Aug 7, 2010, at 4:10 PM, David Chelimsky wrote: >>>>>> >>>>>>> Hey all, >>>>>>> >>>>>>> It turns out that if you have >>>>>>> >>>>>>> * Rails (2 or 3) >>>>>>> * Ruby-1.9 >>>>>>> * a model named Message >>>>>>> * let(:message) or def message in an example group >>>>>>> * a Rails assertion in an example in that group >>>>>>> * note that rspec-rails' matchers delegate to Rails' assertions >>>>>>> >>>>>>> You'll get an error saying "wrong number of arguments (1 for 0)" >>>>>>> >>>>>>> This is because the rails assertion, which, when running with Ruby-1.9, delegates to Minitest::Assertions#assert_block, which delegates to a message() method that it defines. So the message() method defined by let() overrides the message() method in the Assertions module, and results in unexpected and undesirable outcomes. >>>>>>> >>>>>>> So - what should we do? I don't think changing Minitest is really an option, as too many assertion libraries already wrap Minitest assertions. I don't think RSpec should be in the business of monitoring methods end-users define to make sure they're not overriding pre-existing methods (what if you override a method intentionally?). The only thing I'm left with is document this particular case and hope for the best, but that feels unsatisfactory as well. >>>>>>> >>>>>>> Recommendations? Words of wisdom? >>>>>> >>>>>> FYI - here's the issue that spawned this thread: http://github.com/rspec/rspec-rails/issues/152 >>>>> >>>>> Can you use the Assertions module some other way than mixing it into the example (thereby polluting it with the Assertions module's methods?) >>>> >>>> I like the idea in the abstract, but most of the rails assertions rely on some state that is local to the example (@response, @controller, @request, etc, etc). RSpec _could_ gather up all those instance variables and pass them into an assertion-wrapper object, but then it would be highly coupled to that implementation and would lead us down a familiar and unfriendly path of forcing rspec-rails releases for every rails release. That's a world I hope to leave behind with Rails 3 :) >>> >>> So leave the rails assertions mixed into the example, but forward all the calls to the MiniTest::Assertions methods to some other object that has them mixed in. Won't that work? >> >> Here's a prototype implementation: http://github.com/rspec/rspec-rails/commit/0cd384536cf532435ec8f290a9c357b60872acd7 >> >> It's on a branch (http://github.com/rspec/rspec-rails/tree/assertion-delegate) because I'm not convinced this is the right way to go yet, but I'd like some feedback from anyone who wishes to peruse and comment. > > Yeah, that's what I was talking about. Couple of thoughts / questions: > > I'm still not clear why you need to copy the instance variable over though - do the rails assertions get monkey-patched into the Test::Unit::Assertions module then? No - holdover from exploratory session. > Also, how come there's nothing in the specs about the #message method that caused all this? Good point. New patch: http://github.com/rspec/rspec-rails/commit/86600313462638e7becc726e53f1bc67af108667 >> Thanks, >> David >> >>>> It would also eliminate the option to use the Rails assertions directly in examples. >>>> >>>> Oh, well :) >>>> >>>>> cheers, >>>>> Matt >>>>> >>>>> http://blog.mattwynne.net >>>>> +44(0)7974 430184 >>>> >>>> _______________________________________________ >>>> rspec-users mailing list >>>> rspec-users at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/rspec-users >>> >>> cheers, >>> Matt >>> >>> http://blog.mattwynne.net >>> +44(0)7974 430184 >>> >>> _______________________________________________ >>> rspec-users mailing list >>> rspec-users at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rspec-users >> >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users > > cheers, > Matt > > http://blog.mattwynne.net > +44(0)7974 430184 > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users From ashley.moran at patchspace.co.uk Mon Aug 9 08:38:55 2010 From: ashley.moran at patchspace.co.uk (Ashley Moran) Date: Mon, 9 Aug 2010 13:38:55 +0100 Subject: [rspec-users] Order guarantees of let Message-ID: Hi I was just about to replace a `before` block along the lines of: before(:each) do @cti_b_id = service.create(name: "Item-B") @cti_z_id = service.create(name: "Z-Item") @cti_a_id = service.create(name: "Item-A") # ... end with let!(:cti_b_id) { ... } let!(:cti_z_id) { ... } let!(:cti_a_id) { ... } But then I wondered - since the spec depends on the order they are created in (it proves ordering is independent of creation order) - is the run order of `let!` guaranteed? I imagine they run in the order I expect (ie top to bottom), but I wondered if that was an explicitly stated property of RSpec? Cheers Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran From matt at mattwynne.net Mon Aug 9 08:42:13 2010 From: matt at mattwynne.net (Matt Wynne) Date: Mon, 9 Aug 2010 13:42:13 +0100 Subject: [rspec-users] Name collision - how would you handle this? In-Reply-To: References: <958F356A-6B8F-49FF-B89E-C4557E943B2E@gmail.com> <13E563D1-9C62-4C75-A825-7D57F8C166DE@mattwynne.net> <6972E490-0BCD-4225-A9B4-BFA06ECA972A@mattwynne.net> <86BA7B78-9FC9-4DDA-8C6E-79298F9E7ABD@mattwynne.net> Message-ID: On 9 Aug 2010, at 13:04, David Chelimsky wrote: > > On Aug 9, 2010, at 6:37 AM, Matt Wynne wrote: > >> >> On 9 Aug 2010, at 01:54, David Chelimsky wrote: >> >>> >>> On Aug 8, 2010, at 11:13 AM, Matt Wynne wrote: >>> >>>> >>>> On 8 Aug 2010, at 16:53, David Chelimsky wrote: >>>> >>>>> On Aug 8, 2010, at 10:40 AM, Matt Wynne wrote: >>>>>> On 8 Aug 2010, at 16:38, David Chelimsky wrote: >>>>>>> On Aug 7, 2010, at 4:10 PM, David Chelimsky wrote: >>>>>>> >>>>>>>> Hey all, >>>>>>>> >>>>>>>> It turns out that if you have >>>>>>>> >>>>>>>> * Rails (2 or 3) >>>>>>>> * Ruby-1.9 >>>>>>>> * a model named Message >>>>>>>> * let(:message) or def message in an example group >>>>>>>> * a Rails assertion in an example in that group >>>>>>>> * note that rspec-rails' matchers delegate to Rails' assertions >>>>>>>> >>>>>>>> You'll get an error saying "wrong number of arguments (1 for 0)" >>>>>>>> >>>>>>>> This is because the rails assertion, which, when running with Ruby-1.9, delegates to Minitest::Assertions#assert_block, which delegates to a message() method that it defines. So the message() method defined by let() overrides the message() method in the Assertions module, and results in unexpected and undesirable outcomes. >>>>>>>> >>>>>>>> So - what should we do? I don't think changing Minitest is really an option, as too many assertion libraries already wrap Minitest assertions. I don't think RSpec should be in the business of monitoring methods end-users define to make sure they're not overriding pre-existing methods (what if you override a method intentionally?). The only thing I'm left with is document this particular case and hope for the best, but that feels unsatisfactory as well. >>>>>>>> >>>>>>>> Recommendations? Words of wisdom? >>>>>>> >>>>>>> FYI - here's the issue that spawned this thread: http://github.com/rspec/rspec-rails/issues/152 >>>>>> >>>>>> Can you use the Assertions module some other way than mixing it into the example (thereby polluting it with the Assertions module's methods?) >>>>> >>>>> I like the idea in the abstract, but most of the rails assertions rely on some state that is local to the example (@response, @controller, @request, etc, etc). RSpec _could_ gather up all those instance variables and pass them into an assertion-wrapper object, but then it would be highly coupled to that implementation and would lead us down a familiar and unfriendly path of forcing rspec-rails releases for every rails release. That's a world I hope to leave behind with Rails 3 :) >>>> >>>> So leave the rails assertions mixed into the example, but forward all the calls to the MiniTest::Assertions methods to some other object that has them mixed in. Won't that work? >>> >>> Here's a prototype implementation: http://github.com/rspec/rspec-rails/commit/0cd384536cf532435ec8f290a9c357b60872acd7 >>> >>> It's on a branch (http://github.com/rspec/rspec-rails/tree/assertion-delegate) because I'm not convinced this is the right way to go yet, but I'd like some feedback from anyone who wishes to peruse and comment. >> >> Yeah, that's what I was talking about. Couple of thoughts / questions: >> >> I'm still not clear why you need to copy the instance variable over though - do the rails assertions get monkey-patched into the Test::Unit::Assertions module then? > > No - holdover from exploratory session. > >> Also, how come there's nothing in the specs about the #message method that caused all this? > > Good point. > > New patch: http://github.com/rspec/rspec-rails/commit/86600313462638e7becc726e53f1bc67af108667 This is like an extremely sluggish kind of pair programming! What do you think of it now? Is it growing on you? What worries you about it? > >>> Thanks, >>> David >>> >>>>> It would also eliminate the option to use the Rails assertions directly in examples. >>>>> >>>>> Oh, well :) >>>>> >>>>>> cheers, >>>>>> Matt >>>>>> >>>>>> http://blog.mattwynne.net >>>>>> +44(0)7974 430184 >>>>> >>>>> _______________________________________________ >>>>> rspec-users mailing list >>>>> rspec-users at rubyforge.org >>>>> http://rubyforge.org/mailman/listinfo/rspec-users >>>> >>>> cheers, >>>> Matt >>>> >>>> http://blog.mattwynne.net >>>> +44(0)7974 430184 >>>> >>>> _______________________________________________ >>>> rspec-users mailing list >>>> rspec-users at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/rspec-users >>> >>> _______________________________________________ >>> rspec-users mailing list >>> rspec-users at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rspec-users >> >> cheers, >> Matt >> >> http://blog.mattwynne.net >> +44(0)7974 430184 >> >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users cheers, Matt http://blog.mattwynne.net +44(0)7974 430184 From dchelimsky at gmail.com Mon Aug 9 08:49:45 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 9 Aug 2010 07:49:45 -0500 Subject: [rspec-users] Order guarantees of let In-Reply-To: References: Message-ID: On Aug 9, 2010, at 7:38 AM, Ashley Moran wrote: > Hi > > I was just about to replace a `before` block along the lines of: > > before(:each) do > @cti_b_id = service.create(name: "Item-B") > @cti_z_id = service.create(name: "Z-Item") > @cti_a_id = service.create(name: "Item-A") > # ... > end > > with > > let!(:cti_b_id) { ... } > let!(:cti_z_id) { ... } > let!(:cti_a_id) { ... } > > But then I wondered - since the spec depends on the order they are created in (it proves ordering is independent of creation order) - is the run order of `let!` guaranteed? I imagine they run in the order I expect (ie top to bottom), but I wondered if that was an explicitly stated property of RSpec? Yes, eval'd in order. No, not explicitly stated, but I think it should be. Want to submit a patch with a spec for this? > > Cheers > Ash > > -- > http://www.patchspace.co.uk/ > http://www.linkedin.com/in/ashleymoran > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users From dchelimsky at gmail.com Mon Aug 9 09:24:42 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 9 Aug 2010 08:24:42 -0500 Subject: [rspec-users] Name collision - how would you handle this? In-Reply-To: References: <958F356A-6B8F-49FF-B89E-C4557E943B2E@gmail.com> <13E563D1-9C62-4C75-A825-7D57F8C166DE@mattwynne.net> <6972E490-0BCD-4225-A9B4-BFA06ECA972A@mattwynne.net> <86BA7B78-9FC9-4DDA-8C6E-79298F9E7ABD@mattwynne.net> Message-ID: On Aug 9, 2010, at 7:42 AM, Matt Wynne wrote: > > On 9 Aug 2010, at 13:04, David Chelimsky wrote: > >> >> On Aug 9, 2010, at 6:37 AM, Matt Wynne wrote: >> >>> >>> On 9 Aug 2010, at 01:54, David Chelimsky wrote: >>> >>>> >>>> On Aug 8, 2010, at 11:13 AM, Matt Wynne wrote: >>>> >>>>> >>>>> On 8 Aug 2010, at 16:53, David Chelimsky wrote: >>>>> >>>>>> On Aug 8, 2010, at 10:40 AM, Matt Wynne wrote: >>>>>>> On 8 Aug 2010, at 16:38, David Chelimsky wrote: >>>>>>>> On Aug 7, 2010, at 4:10 PM, David Chelimsky wrote: >>>>>>>> >>>>>>>>> Hey all, >>>>>>>>> >>>>>>>>> It turns out that if you have >>>>>>>>> >>>>>>>>> * Rails (2 or 3) >>>>>>>>> * Ruby-1.9 >>>>>>>>> * a model named Message >>>>>>>>> * let(:message) or def message in an example group >>>>>>>>> * a Rails assertion in an example in that group >>>>>>>>> * note that rspec-rails' matchers delegate to Rails' assertions >>>>>>>>> >>>>>>>>> You'll get an error saying "wrong number of arguments (1 for 0)" >>>>>>>>> >>>>>>>>> This is because the rails assertion, which, when running with Ruby-1.9, delegates to Minitest::Assertions#assert_block, which delegates to a message() method that it defines. So the message() method defined by let() overrides the message() method in the Assertions module, and results in unexpected and undesirable outcomes. >>>>>>>>> >>>>>>>>> So - what should we do? I don't think changing Minitest is really an option, as too many assertion libraries already wrap Minitest assertions. I don't think RSpec should be in the business of monitoring methods end-users define to make sure they're not overriding pre-existing methods (what if you override a method intentionally?). The only thing I'm left with is document this particular case and hope for the best, but that feels unsatisfactory as well. >>>>>>>>> >>>>>>>>> Recommendations? Words of wisdom? >>>>>>>> >>>>>>>> FYI - here's the issue that spawned this thread: http://github.com/rspec/rspec-rails/issues/152 >>>>>>> >>>>>>> Can you use the Assertions module some other way than mixing it into the example (thereby polluting it with the Assertions module's methods?) >>>>>> >>>>>> I like the idea in the abstract, but most of the rails assertions rely on some state that is local to the example (@response, @controller, @request, etc, etc). RSpec _could_ gather up all those instance variables and pass them into an assertion-wrapper object, but then it would be highly coupled to that implementation and would lead us down a familiar and unfriendly path of forcing rspec-rails releases for every rails release. That's a world I hope to leave behind with Rails 3 :) >>>>> >>>>> So leave the rails assertions mixed into the example, but forward all the calls to the MiniTest::Assertions methods to some other object that has them mixed in. Won't that work? >>>> >>>> Here's a prototype implementation: http://github.com/rspec/rspec-rails/commit/0cd384536cf532435ec8f290a9c357b60872acd7 >>>> >>>> It's on a branch (http://github.com/rspec/rspec-rails/tree/assertion-delegate) because I'm not convinced this is the right way to go yet, but I'd like some feedback from anyone who wishes to peruse and comment. >>> >>> Yeah, that's what I was talking about. Couple of thoughts / questions: >>> >>> I'm still not clear why you need to copy the instance variable over though - do the rails assertions get monkey-patched into the Test::Unit::Assertions module then? >> >> No - holdover from exploratory session. >> >>> Also, how come there's nothing in the specs about the #message method that caused all this? >> >> Good point. >> >> New patch: http://github.com/rspec/rspec-rails/commit/86600313462638e7becc726e53f1bc67af108667 > > This is like an extremely sluggish kind of pair programming! > > What do you think of it now? Is it growing on you? What worries you about it? Not sure yet. On one hand it feels sort of unnecessary, but on the other, it does solve this particular anomaly. I'm going to sit on it for a day or two and see if any specific arguments against come to mind. In the mean time, other opinions would be welcome. Cheers, David > >> >>>> Thanks, >>>> David >>>> >>>>>> It would also eliminate the option to use the Rails assertions directly in examples. >>>>>> >>>>>> Oh, well :) >>>>>> >>>>>>> cheers, >>>>>>> Matt >>>>>>> >>>>>>> http://blog.mattwynne.net >>>>>>> +44(0)7974 430184 >>>>>> >>>>>> _______________________________________________ >>>>>> rspec-users mailing list >>>>>> rspec-users at rubyforge.org >>>>>> http://rubyforge.org/mailman/listinfo/rspec-users >>>>> >>>>> cheers, >>>>> Matt >>>>> >>>>> http://blog.mattwynne.net >>>>> +44(0)7974 430184 >>>>> >>>>> _______________________________________________ >>>>> rspec-users mailing list >>>>> rspec-users at rubyforge.org >>>>> http://rubyforge.org/mailman/listinfo/rspec-users >>>> >>>> _______________________________________________ >>>> rspec-users mailing list >>>> rspec-users at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/rspec-users >>> >>> cheers, >>> Matt >>> >>> http://blog.mattwynne.net >>> +44(0)7974 430184 >>> >>> _______________________________________________ >>> rspec-users mailing list >>> rspec-users at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rspec-users >> >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users > > cheers, > Matt > > http://blog.mattwynne.net > +44(0)7974 430184 > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users From rick.denatale at gmail.com Mon Aug 9 10:56:07 2010 From: rick.denatale at gmail.com (Rick DeNatale) Date: Mon, 9 Aug 2010 10:56:07 -0400 Subject: [rspec-users] Recognising RSpec files in the Textmate bundle In-Reply-To: References: <8AC70538-323C-4DF6-9F67-64783028922C@patchspace.co.uk> <4C5E05B0.2060600@gmail.com> <9085C71F-DE9C-433B-AE66-8F471BE2C183@patchspace.co.uk> <4C5F1931.6020604@gmail.com> Message-ID: On Sun, Aug 8, 2010 at 11:45 PM, Elliot Winkler wrote: > On Sun, Aug 8, 2010 at 3:53 PM, Phillip Koebbe > wrote: >> >> Here's another idea that's not so great, but maybe it will spur some >> thinking in someone else. What about a custom generator (or a flag on the >> official one) that added something like a shebang line at the beginning of >> example files. A short comment that identifies the file, like "# RSpec". >> Then a TM bundle could pick up on that and be happy. > > Putting aside the fact that this is solving a very specific problem.... what > about #!/usr/bin/env spec ? 99% of the time the shebang won't be used, I'd > wager, so it'd pretty much be harmless. As I tried to point out, textmate looks for shebang lines to compare against in the language definitions. Right now the rspec bundle doesn't have a language definition since rspec files are really ruby files and want to use that language definition. I guess I just don't see what's wrong with using the convention of naming spec files with the suffix _spec.rb as Mr. Textmate suggests http://blog.macromates.com/2007/file-type-detection-rspec-rails/ It's worked well for me for quite some time. -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Github: http://github.com/rubyredrick Twitter: @RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale From rick.denatale at gmail.com Mon Aug 9 11:06:36 2010 From: rick.denatale at gmail.com (Rick DeNatale) Date: Mon, 9 Aug 2010 11:06:36 -0400 Subject: [rspec-users] Order guarantees of let In-Reply-To: References: Message-ID: On Mon, Aug 9, 2010 at 8:49 AM, David Chelimsky wrote: > > On Aug 9, 2010, at 7:38 AM, Ashley Moran wrote: > >> Hi >> >> I was just about to replace a `before` block along the lines of: >> >> ?before(:each) do >> ? ?@cti_b_id = service.create(name: "Item-B") >> ? ?@cti_z_id = service.create(name: "Z-Item") >> ? ?@cti_a_id = service.create(name: "Item-A") >> ? ?# ... >> ?end >> >> with >> >> ? let!(:cti_b_id) { ... } >> ? let!(:cti_z_id) { ... } >> ? let!(:cti_a_id) { ... } >> >> But then I wondered - since the spec depends on the order they are created in (it proves ordering is independent of creation order) - is the run order of `let!` guaranteed? ?I imagine they run in the order I expect (ie top to bottom), but I wondered if that was an explicitly stated property of RSpec? > > Yes, eval'd in order. No, not explicitly stated, but I think it should be. Want to submit a patch with a spec for this? But, First of all, what's let! as opposed to let, I can't seem to find it via google or the latest draft of the book. Second, unless let! is a new method which not only defines the memoized method but invokes it, then the order of evaluation will depend on the order the generated let methods are invoked in the example won't it? -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Github: http://github.com/rubyredrick Twitter: @RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale From dchelimsky at gmail.com Mon Aug 9 11:21:05 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 9 Aug 2010 10:21:05 -0500 Subject: [rspec-users] Order guarantees of let In-Reply-To: References: Message-ID: On Aug 9, 2010, at 10:06 AM, Rick DeNatale wrote: > On Mon, Aug 9, 2010 at 8:49 AM, David Chelimsky wrote: >> >> On Aug 9, 2010, at 7:38 AM, Ashley Moran wrote: >> >>> Hi >>> >>> I was just about to replace a `before` block along the lines of: >>> >>> before(:each) do >>> @cti_b_id = service.create(name: "Item-B") >>> @cti_z_id = service.create(name: "Z-Item") >>> @cti_a_id = service.create(name: "Item-A") >>> # ... >>> end >>> >>> with >>> >>> let!(:cti_b_id) { ... } >>> let!(:cti_z_id) { ... } >>> let!(:cti_a_id) { ... } >>> >>> But then I wondered - since the spec depends on the order they are created in (it proves ordering is independent of creation order) - is the run order of `let!` guaranteed? I imagine they run in the order I expect (ie top to bottom), but I wondered if that was an explicitly stated property of RSpec? >> >> Yes, eval'd in order. No, not explicitly stated, but I think it should be. Want to submit a patch with a spec for this? > > But, > > First of all, what's let! as opposed to let, I can't seem to find it > via google or the latest draft of the book. http://rdoc.info/projects/rspec/rspec-core - search for let and let! > > Second, unless let! is a new method which not only defines the > memoized method but invokes it That's what it is. Sort of. It gets invoked by an implicit before hook which is added - those get eval'd in the order in which they get defined. > , then the order of evaluation will > depend on the order the generated let methods are invoked in the > example won't it? > > > -- > Rick DeNatale > > Blog: http://talklikeaduck.denhaven2.com/ > Github: http://github.com/rubyredrick > Twitter: @RickDeNatale > WWR: http://www.workingwithrails.com/person/9021-rick-denatale > LinkedIn: http://www.linkedin.com/in/rickdenatale > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users From dchelimsky at gmail.com Mon Aug 9 11:23:32 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 9 Aug 2010 10:23:32 -0500 Subject: [rspec-users] Recognising RSpec files in the Textmate bundle In-Reply-To: References: <8AC70538-323C-4DF6-9F67-64783028922C@patchspace.co.uk> <4C5E05B0.2060600@gmail.com> <9085C71F-DE9C-433B-AE66-8F471BE2C183@patchspace.co.uk> <4C5F1931.6020604@gmail.com> Message-ID: On Aug 9, 2010, at 9:56 AM, Rick DeNatale wrote: > On Sun, Aug 8, 2010 at 11:45 PM, Elliot Winkler > wrote: >> On Sun, Aug 8, 2010 at 3:53 PM, Phillip Koebbe >> wrote: >>> >>> Here's another idea that's not so great, but maybe it will spur some >>> thinking in someone else. What about a custom generator (or a flag on the >>> official one) that added something like a shebang line at the beginning of >>> example files. A short comment that identifies the file, like "# RSpec". >>> Then a TM bundle could pick up on that and be happy. >> >> Putting aside the fact that this is solving a very specific problem.... what >> about #!/usr/bin/env spec ? 99% of the time the shebang won't be used, I'd >> wager, so it'd pretty much be harmless. > > As I tried to point out, textmate looks for shebang lines to compare > against in the language definitions. Right now the rspec bundle > doesn't have a language definition since rspec files are really ruby > files and want to use that language definition. > > I guess I just don't see what's wrong with using the convention of > naming spec files with the suffix _spec.rb as Mr. Textmate suggests > http://blog.macromates.com/2007/file-type-detection-rspec-rails/ > > It's worked well for me for quite some time. Hey Rick, Shared groups are typically stored in a file that has a different name, and ppl want access to all the code completion and syntax highlighting of spec files in those files. HTH, David > -- > Rick DeNatale > > Blog: http://talklikeaduck.denhaven2.com/ > Github: http://github.com/rubyredrick > Twitter: @RickDeNatale > WWR: http://www.workingwithrails.com/person/9021-rick-denatale > LinkedIn: http://www.linkedin.com/in/rickdenatale > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users From rick.denatale at gmail.com Mon Aug 9 12:37:15 2010 From: rick.denatale at gmail.com (Rick DeNatale) Date: Mon, 9 Aug 2010 12:37:15 -0400 Subject: [rspec-users] Recognising RSpec files in the Textmate bundle In-Reply-To: References: <8AC70538-323C-4DF6-9F67-64783028922C@patchspace.co.uk> <4C5E05B0.2060600@gmail.com> <9085C71F-DE9C-433B-AE66-8F471BE2C183@patchspace.co.uk> <4C5F1931.6020604@gmail.com> Message-ID: On Mon, Aug 9, 2010 at 11:23 AM, David Chelimsky wrote: > > On Aug 9, 2010, at 9:56 AM, Rick DeNatale wrote: > >> On Sun, Aug 8, 2010 at 11:45 PM, Elliot Winkler >> wrote: >>> On Sun, Aug 8, 2010 at 3:53 PM, Phillip Koebbe >>> wrote: >>>> >>>> Here's another idea that's not so great, but maybe it will spur some >>>> thinking in someone else. What about a custom generator (or a flag on the >>>> official one) that added something like a shebang line at the beginning of >>>> example files. A short comment that identifies the file, like "# RSpec". >>>> Then a TM bundle could pick up on that and be happy. >>> >>> Putting aside the fact that this is solving a very specific problem.... what >>> about #!/usr/bin/env spec ? 99% of the time the shebang won't be used, I'd >>> wager, so it'd pretty much be harmless. >> >> As I tried to point out, textmate looks for shebang lines to compare >> against in the language definitions. ?Right now the rspec bundle >> doesn't have a language definition since rspec files are really ruby >> files and want to use that language definition. >> >> I guess I just don't see what's wrong with using the convention of >> naming spec files with the suffix _spec.rb as Mr. Textmate suggests >> http://blog.macromates.com/2007/file-type-detection-rspec-rails/ >> >> It's worked well for me for quite some time. > > Hey Rick, > > Shared groups are typically stored in a file that has a different name, and ppl want access to all the code completion and syntax highlighting of spec files in those files. Well, I'd still use a different file name suffix which I could set textmate to recognize as a spec _sspec.rb or _sgroup.rb something like that. If TM 2 ever sees the light of day, maybe there will be alternatives, but ... -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Github: http://github.com/rubyredrick Twitter: @RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale From christoffer.klang at gmail.com Sun Aug 8 15:53:26 2010 From: christoffer.klang at gmail.com (christofferklang) Date: Sun, 8 Aug 2010 12:53:26 -0700 (PDT) Subject: [rspec-users] issue with rescue_action_in_public! and testing 404 responses Message-ID: <29382281.post@talk.nabble.com> Hello, I'm new to rails and I'm trying to wrap my heads around how to spec controllers using RSpec (using rails 3rc1 and rspec 2.0.0.beta.19). The problem I've run into is when I want to test that my controllers respond with a 404 for unfound records. Whenever I run the spec, the ActiveRecord::RecordNotFound exception is not caught by rails, causing the spec example to fail since the exception propagates out of the controller into the spec. >From googling around I get that rails only handles the exceptions and does a 404 response when it's run in production mode, and that you need to call rescue_action_in_public! in your example if you want this behavior for test mode. However, this does not seem to do anything for me. The example still fails because the exception bubbles escapes unhandled from the controller. Do I need to set something up for the rescue_action_in_public! to work? Or is this not the correct way to test missing records? My full example: (using factory_girl, rspec mocks and devise) it "respons with 404 when trying to edit non-existing reads" do rescue_action_in_public! sign_in(@user) Read.should_receive(:find_by_id_and_user_id!).with(2, @user.id).and_raise(ActiveRecord::RecordNotFound) get :edit, :id => 2 response.status.should eql 404 end and the exception: 1) ReadsController resources respons with 404 for non existing reads for GET /reads/2/edit Failure/Error: get :edit, :id => 2 ActiveRecord::RecordNotFound Thanks, /Christoffer -- View this message in context: http://old.nabble.com/issue-with-rescue_action_in_public%21-and-testing-404-responses-tp29382281p29382281.html Sent from the rspec-users mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From francois.beausoleil at gmail.com Sun Aug 8 16:42:31 2010 From: francois.beausoleil at gmail.com (=?ISO-8859-1?Q?Fran=E7ois_Beausoleil?=) Date: Sun, 8 Aug 2010 13:42:31 -0700 (PDT) Subject: [rspec-users] Bad gemspec for rspec-core Message-ID: I receive this message when bundling using this example project: http://github.com/francois/rental_agency/tree/1ea252624e161ddc305a719d505a633d8d464e49 The included Gemfile references HEAD of rspec-core, and the gemspec there has this issue: Using rspec-core (2.0.0.beta.19) from git://github.com/rspec/rspec-core.git (at master) rspec-core at /Users/francois/.rvm/gems/ruby-1.9.2-rc2/bundler/gems/ rspec-core-3eb4494 did not have a valid gemspec. This prevents bundler from installing bins or native extensions, but that may not affect its functionality. The validation message from Rubygems was: ["lib/rspec/core/kernel_extensions.rb", "lib/rspec/core/ object_extensions.rb"] are not files I only had to refresh the gemspec in the rspec-core repository to fix this, which I've done here: http://github.com/francois/rspec-core/commit/52d08099a263f092423b58b1e9a9ed4e8589f7f8 Thanks! Fran?ois From dchelimsky at gmail.com Mon Aug 9 22:21:40 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 9 Aug 2010 21:21:40 -0500 Subject: [rspec-users] issue with rescue_action_in_public! and testing 404 responses In-Reply-To: <29382281.post@talk.nabble.com> References: <29382281.post@talk.nabble.com> Message-ID: <8AF62E18-794E-40B2-BB82-95B2A21FDB9B@gmail.com> On Aug 8, 2010, at 2:53 PM, christofferklang wrote: > Hello, > I'm new to rails and I'm trying to wrap my heads around how to spec controllers using RSpec (using rails 3rc1 and rspec 2.0.0.beta.19). > > The problem I've run into is when I want to test that my controllers respond with a 404 for unfound records. Whenever I run the spec, the ActiveRecord::RecordNotFound exception is not caught by rails, causing the spec example to fail since the exception propagates out of the controller into the spec. > > >From googling around I get that rails only handles the exceptions and does a 404 response when it's run in production mode, and that you need to call rescue_action_in_public! in your example if you want this behavior for test mode. However, this does not seem to do anything for me. The example still fails because the exception bubbles escapes unhandled from the controller. > > Do I need to set something up for the rescue_action_in_public! to work? Or is this not the correct way to test missing records? > > My full example: (using factory_girl, rspec mocks and devise) > > > it "respons with 404 when trying to edit non-existing reads" do > rescue_action_in_public! > sign_in(@user) > Read.should_receive(:find_by_id_and_user_id!).with(2, @user.id).and_raise(ActiveRecord::RecordNotFound) > > get :edit, :id => 2 > response.status.should eql 404 > end > > > and the exception: > 1) ReadsController resources respons with 404 for non existing reads for GET /reads/2/edit > Failure/Error: get :edit, :id => 2 > ActiveRecord::RecordNotFound It's up to you to handle the error in the controller. Something like this in ApplicationController: rescue_from ActiveRecord::RecordNotFound do render '/404.html', :layout => false, :status => :not_found end HTH, David > Thanks, /Christoffer -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at ruby-forum.com Tue Aug 10 04:30:39 2010 From: lists at ruby-forum.com (Aruna Chinnamuthu) Date: Tue, 10 Aug 2010 10:30:39 +0200 Subject: [rspec-users] how to place the app in the rails dir Message-ID: Hi i am new to ROR . I have mentioned to work on Rspec.. i have a code given by my boss.. I am having doubts in using them. 1. How should i keep that code in my railsprojects directory.. Should i keep the package given by them directly in my directory or i have to use rails appname 2.I actually tried by keeping the code in my rails dir and changes the database.yml file But when i try to run script/server . i am getting an error as /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require': no such file to load -- feedzirra (MissingSourceFile) y so ?? Pls guide me .. -- Posted via http://www.ruby-forum.com/. From lists at ruby-forum.com Tue Aug 10 07:27:16 2010 From: lists at ruby-forum.com (Aruna Chinnamuthu) Date: Tue, 10 Aug 2010 13:27:16 +0200 Subject: [rspec-users] Cant able to create a Rspec files Message-ID: <1b0a995afc4d161a9786688fd3f9bcf0@ruby-forum.com> Hi, I am new to ROR. I am working on Rspec.. I have been provided with a full package of an application. I kept it in my rails dir. The dir itself contains spec folder with some controllers/models and fixtures but without spec_helper file. So when i run $spec spec/ i got an error /usr/lib/ruby/gems/1.8/gems/rspec-1.3.0/lib/spec/runner/options.rb:283:in `files_to_load': File or directory not found: spec/ (RuntimeError) So i simply deleted the whole spec folder. And again created a new spec by aruna at aruna-desktop:~/railsprojects/appname_c$ script/generate rspec Configuring rspec and rspec-rails gems in config/environments/test.rb ... exists lib/tasks create lib/tasks/rspec.rake create script/autospec create script/spec create spec create spec/rcov.opts create spec/spec.opts create spec/spec_helper.rb aruna at aruna-desktop:~/railsprojects/appname_c$ after all this .. I try to add the testing spec for my controller Users by aruna at aruna-desktop:~/railsprojects/appname_c$ script/generate rspec_controller Users new The name 'UsersController' is either already used in your application or reserved by Ruby on Rails. Please choose an alternative and run this generator again. aruna at aruna-desktop:~/railsprojects/appname_c$ I am getting the error as above .. Pls give me suggestions of why i am getting this error. How to resolve this one.. -- Posted via http://www.ruby-forum.com/. From dchelimsky at gmail.com Tue Aug 10 09:26:43 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 10 Aug 2010 08:26:43 -0500 Subject: [rspec-users] Cant able to create a Rspec files In-Reply-To: <1b0a995afc4d161a9786688fd3f9bcf0@ruby-forum.com> References: <1b0a995afc4d161a9786688fd3f9bcf0@ruby-forum.com> Message-ID: On Aug 10, 2010, at 6:27 AM, Aruna Chinnamuthu wrote: > Hi, > > I am new to ROR. I am working on Rspec.. > I have been provided with a full package of an application. > I kept it in my rails dir. > The dir itself contains spec folder with some controllers/models and > fixtures but without spec_helper file. > So when i run $spec spec/ i got an error > > /usr/lib/ruby/gems/1.8/gems/rspec-1.3.0/lib/spec/runner/options.rb:283:in > `files_to_load': File or directory not found: spec/ (RuntimeError) > > So i simply deleted the whole spec folder. > And again created a new spec by > > aruna at aruna-desktop:~/railsprojects/appname_c$ script/generate rspec > Configuring rspec and rspec-rails gems in config/environments/test.rb > ... > > exists lib/tasks > create lib/tasks/rspec.rake > create script/autospec > create script/spec > create spec > create spec/rcov.opts > create spec/spec.opts > create spec/spec_helper.rb > > > aruna at aruna-desktop:~/railsprojects/appname_c$ > > > after all this .. I try to add the testing spec for my controller Users > by > > aruna at aruna-desktop:~/railsprojects/appname_c$ script/generate > rspec_controller Users new > The name 'UsersController' is either already used in your > application or reserved by Ruby on Rails. > Please choose an alternative and run this generator again. > aruna at aruna-desktop:~/railsprojects/appname_c$ > > I am getting the error as above .. > Pls give me suggestions of why i am getting this error. > How to resolve this one.. Hi Aruna, I see that this is all a bit new for you, so here are a couple of things you may not understand. The people who participate in this mailing list are here to help you, but we all volunteer our time to do this. This means that you have a responsibility to research things on your own before you ask questions here. I'm not talking hours of research, but in this case a simple google search will point you to the answer to your question. [1] If you do a search like that and find that you are confused by the information that _is_ available, then by all means, please feel free to write us here with links to the confusing information and we'll either try to help or try to point you to a better resource (for example, this question is really a Rails question, not an RSpec question, so we'd likely point you to the Rails mailing list [2] for assistance). I realize this may seem a bit off-puttting, but if you peruse our archives I think you'll see that we're actually a pretty helpful bunch, and we do look forward to helping you with your questions about RSpec. Cheers, David [1] http://lmgtfy.com/?q=The+name+%27UsersController%27+is+either+already+used+in+your+application+or+reserved+by+Ruby+on+Rails. [2] http://groups.google.com/group/rubyonrails-talk > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users From ashley.moran at patchspace.co.uk Tue Aug 10 09:40:50 2010 From: ashley.moran at patchspace.co.uk (Ashley Moran) Date: Tue, 10 Aug 2010 14:40:50 +0100 Subject: [rspec-users] Recognising RSpec files in the Textmate bundle In-Reply-To: References: <8AC70538-323C-4DF6-9F67-64783028922C@patchspace.co.uk> <4C5E05B0.2060600@gmail.com> <9085C71F-DE9C-433B-AE66-8F471BE2C183@patchspace.co.uk> <4C5F1931.6020604@gmail.com> Message-ID: <3790E051-3F25-4919-8A23-4F4248EA7767@patchspace.co.uk> On 9 Aug 2010, at 17:37, Rick DeNatale wrote: > Well, I'd still use a different file name suffix which I could set > textmate to recognize as a spec > > _sspec.rb or _sgroup.rb > > something like that. Hi Rick, I think that was what David was saying? (If I understood you both correctly, that is.) It's not enough to treat RSpec files as Ruby because they have too many specific highlighting rules and completions etc, which we don't want mixed into plain Ruby source. My specific example is I now have three files "*_contract.rb" that I'd like highlighted. But if everyone chipped in with their own convention we'd probably end in chaos. I like the "_sgroup.rb" idea though. Or maybe "_examples.rb"? That's fairly generic. Or... how about an actual dot-suffix, ".rspec", eg, "active_record_associations.rspec", which would be designed to indicate an RSpec-loadable file (prob shared example groups), but one that doesn't make sense to run alone (or can't be)? Any legs in that idea? Cheers Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran From ashley.moran at patchspace.co.uk Tue Aug 10 09:50:16 2010 From: ashley.moran at patchspace.co.uk (Ashley Moran) Date: Tue, 10 Aug 2010 14:50:16 +0100 Subject: [rspec-users] Recognising RSpec files in the Textmate bundle In-Reply-To: <4C5F1931.6020604@gmail.com> References: <8AC70538-323C-4DF6-9F67-64783028922C@patchspace.co.uk> <4C5E05B0.2060600@gmail.com> <9085C71F-DE9C-433B-AE66-8F471BE2C183@patchspace.co.uk> <4C5F1931.6020604@gmail.com> Message-ID: <54BD4211-EEB7-4FD4-9AAF-B2B47D7527AC@patchspace.co.uk> On 8 Aug 2010, at 21:53, Phillip Koebbe wrote: > I don't think you are alone in your quest to achieve greater organization. I am guessing that in your suggested RSpec folder structure, the current folders of controllers|helpers|models|views would all live under examples? I might go for that. I think some (many?) might say that it's an unnecessary level, but I think I'd prefer that. I might even look into doing that anyway :) After all, my Cucumber folder structure is > > cuke/ > features/ > steps/ > support/ > > And I use subfolders under features and steps just like I do in RSpec. > Right. I wouldn't want a particular structure to be forced upon me, so I'd rather not see that happen to anyone. The biggest problem I can see is the RSpec TMBundle's "Alternate File" command, which I would probably sacrifice a finger to keep*. Autotest is easy enough to reconfigure to look in different spec subdirs. If only there was some way of integrating Alternate File and Autotest mappings... Ash * But since I'm still typing 9-fingered after I trapped one under a weight in a gym, I consider this pre-payed. So nobody mess with Alternate File!!! Until my finger is better anyway. -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran From ashley.moran at patchspace.co.uk Tue Aug 10 09:53:30 2010 From: ashley.moran at patchspace.co.uk (Ashley Moran) Date: Tue, 10 Aug 2010 14:53:30 +0100 Subject: [rspec-users] Order guarantees of let In-Reply-To: References: Message-ID: <4D099227-9CAC-495B-BA1A-D694D2BD4C07@patchspace.co.uk> On 9 Aug 2010, at 13:49, David Chelimsky wrote: > Yes, eval'd in order. No, not explicitly stated, but I think it should be. Want to submit a patch with a spec for this? Sure - I've made an action to write a spec for this. I guess the implementation is not likely to change any time soon so I'll do it when I find a convenient 10 mins... Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran From rick.denatale at gmail.com Tue Aug 10 10:03:40 2010 From: rick.denatale at gmail.com (Rick DeNatale) Date: Tue, 10 Aug 2010 10:03:40 -0400 Subject: [rspec-users] Recognising RSpec files in the Textmate bundle In-Reply-To: <3790E051-3F25-4919-8A23-4F4248EA7767@patchspace.co.uk> References: <8AC70538-323C-4DF6-9F67-64783028922C@patchspace.co.uk> <4C5E05B0.2060600@gmail.com> <9085C71F-DE9C-433B-AE66-8F471BE2C183@patchspace.co.uk> <4C5F1931.6020604@gmail.com> <3790E051-3F25-4919-8A23-4F4248EA7767@patchspace.co.uk> Message-ID: On Tue, Aug 10, 2010 at 9:40 AM, Ashley Moran wrote: > > On 9 Aug 2010, at 17:37, Rick DeNatale wrote: > >> Well, I'd still use a different file name suffix which I could set >> textmate to recognize as a spec >> >> _sspec.rb or _sgroup.rb >> >> something like that. > > Hi Rick, > > I think that was what David was saying? ?(If I understood you both correctly, that is.) > > It's not enough to treat RSpec files as Ruby because they have too many specific highlighting rules and completions etc, which we don't want mixed into plain Ruby source. Yeah, I see that the RSpec bundle actually does have a Language definition, somehow I missed that when I looked before. > > My specific example is I now have three files "*_contract.rb" that I'd like highlighted. ?But if everyone chipped in with their own convention we'd probably end in chaos. > > I like the "_sgroup.rb" idea though. ?Or maybe "_examples.rb"? ?That's fairly generic. And easy to add yourself by just editing the bundle. > > Or... how about an actual dot-suffix, ".rspec", eg, "active_record_associations.rspec", which would be designed to indicate an RSpec-loadable file (prob shared example groups), but one that doesn't make sense to run alone (or can't be)? ?Any legs in that idea? I don't think I like that. For one thing most folks don't include the dot suffix in require 'statements'. -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Github: http://github.com/rubyredrick Twitter: @RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale From rick.denatale at gmail.com Tue Aug 10 10:08:48 2010 From: rick.denatale at gmail.com (Rick DeNatale) Date: Tue, 10 Aug 2010 10:08:48 -0400 Subject: [rspec-users] Order guarantees of let In-Reply-To: References: Message-ID: On Mon, Aug 9, 2010 at 11:21 AM, David Chelimsky wrote: >> First of all, what's let! as opposed to let, I can't seem to find it >> via google or the latest draft of the book. > > http://rdoc.info/projects/rspec/rspec-core - search for let and let! > >> >> Second, unless let! is a new method which not only defines the >> memoized method but invokes it > > That's what it is. Sort of. It gets invoked by an implicit before hook which is added - those get eval'd in the order in which they get defined. Makes sense. So is it not (going to be) mentioned in the book, it doesn't seem to be in Beta 15.0 supposedly the final beta version. -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Github: http://github.com/rubyredrick Twitter: @RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale From ashley.moran at patchspace.co.uk Tue Aug 10 10:26:59 2010 From: ashley.moran at patchspace.co.uk (Ashley Moran) Date: Tue, 10 Aug 2010 15:26:59 +0100 Subject: [rspec-users] Recognising RSpec files in the Textmate bundle In-Reply-To: References: <8AC70538-323C-4DF6-9F67-64783028922C@patchspace.co.uk> <4C5E05B0.2060600@gmail.com> <9085C71F-DE9C-433B-AE66-8F471BE2C183@patchspace.co.uk> <4C5F1931.6020604@gmail.com> <3790E051-3F25-4919-8A23-4F4248EA7767@patchspace.co.uk> Message-ID: <4ECF529A-56D5-4D10-9C70-936653BB1651@patchspace.co.uk> On 10 Aug 2010, at 15:03, Rick DeNatale wrote: > And easy to add yourself by just editing the bundle. I've tried this before. Unfortunately, it just leads to pain when you try to update the bundle via Git >> Or... how about an actual dot-suffix, ".rspec", eg, "active_record_associations.rspec", which would be designed to indicate an RSpec-loadable file (prob shared example groups), but one that doesn't make sense to run alone (or can't be)? Any legs in that idea? > > I don't think I like that. For one thing most folks don't include the > dot suffix in require 'statements'. Good point, I forgot about that. Cheers Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran From dchelimsky at gmail.com Tue Aug 10 10:35:33 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 10 Aug 2010 09:35:33 -0500 Subject: [rspec-users] Order guarantees of let In-Reply-To: References: Message-ID: On Aug 10, 2010, at 9:08 AM, Rick DeNatale wrote: > On Mon, Aug 9, 2010 at 11:21 AM, David Chelimsky wrote: >>> First of all, what's let! as opposed to let, I can't seem to find it >>> via google or the latest draft of the book. >> >> http://rdoc.info/projects/rspec/rspec-core - search for let and let! >> >>> >>> Second, unless let! is a new method which not only defines the >>> memoized method but invokes it >> >> That's what it is. Sort of. It gets invoked by an implicit before hook which is added - those get eval'd in the order in which they get defined. > > Makes sense. So is it not (going to be) mentioned in the book, it > doesn't seem to be in Beta 15.0 supposedly the final beta version. Correct. At this point in the production process (indexing) there is no room to add new technical content to the book. > -- > Rick DeNatale > > Blog: http://talklikeaduck.denhaven2.com/ > Github: http://github.com/rubyredrick > Twitter: @RickDeNatale > WWR: http://www.workingwithrails.com/person/9021-rick-denatale > LinkedIn: http://www.linkedin.com/in/rickdenatale > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users From kmandrup.github at gmail.com Tue Aug 10 20:02:18 2010 From: kmandrup.github at gmail.com (Kristian Mandrup) Date: Tue, 10 Aug 2010 17:02:18 -0700 (PDT) Subject: [rspec-users] Nice little DSL trick for extending ExampleGroups in RSpec Message-ID: describe 'migration_generator' do include RSpec::Rails::Orm::ActiveRecord include RSpec::Rails::Migration ... end Didn't quite feel right. So I made it prettier DSL like using the solution below ;) class Class def use_orm orm class_eval do include "RSpec::Rails::Orm::#{orm.to_s.camelize}".constantize end end def specify_for type raise ArgumentError, "Can not specify for #{type}" if ! [:migration, :model].include?(type) class_eval do include "RSpec::Rails::#{type.to_s.camelize}".constantize end end end describe 'migration_generator' do use_orm :active_record specify_for :migration ... end Could it be done in a better way without polluting Class or some other low lv Ruby class? I want the functions from the included module to be avalable within all my: before, after, it, describe etc. blocks. From dhf0820 at gmail.com Tue Aug 10 22:24:58 2010 From: dhf0820 at gmail.com (Don French) Date: Tue, 10 Aug 2010 19:24:58 -0700 (PDT) Subject: [rspec-users] Autotest does not start Message-ID: I have a non rails app using rspec2. I created the autotest/ discover.rb and put in it Autotest.add_discovery {"rspec2"}. When I run under bundler I get - loading autotest/rspec2 and a prompt back When standalone I get: loading autotest/rspec2 style: Rspec2 and a prompt. Any ideasas to the problem. I am sure I am missing something because there is no rails involved. Mahalo Don French From thecatwasnot at gmail.com Tue Aug 10 23:45:39 2010 From: thecatwasnot at gmail.com (Pixel) Date: Tue, 10 Aug 2010 22:45:39 -0500 Subject: [rspec-users] Rspec2, Autotest showing failure on all passing specs Message-ID: Hey guys, This is making me nuts, and I've run out of things to google. I'm writing myself a little gem library, primarily for my own education.? I got a healthy start on my specs and figured I could do myself a favor and get the specs running under autotest.? It's not working quite like I expected.? My specs all pass, but autotest is showing red instead of green.? I've uploaded a screenshot of what I'm seeing, since I don't have a specific error to report. http://img580.imageshack.us/img580/3396/screenshotterminal08111.png You can see rspec is working fine without autotest. I'm looking for two things here: a) How do I get more information out of autotest and/or rspec about this apparent error? I've tried various incantations involving --verbose and -b and nothing seems to be getting at the information I want. b) How do I fix this? I'd be happy to do more googling but I don't know what to look for anymore, various combinations of 'autotest' 'failure' 'rspec' 'rspec2' arn't getting me the information I need and I don't know what other keywords I can use. I've gisted some of my configuration type files in hopes that I've just missed some simple setup (I used jeweler to start the setup, but it's setup for rspec1 not rspec2 so I wonder if that's where the problem originated?) You can see those here: http://gist.github.com/518386 (I'd be happy to include more if it's useful.) Off to try and reproduce this on a fresh gemset.... -Cole From dchelimsky at gmail.com Wed Aug 11 01:21:52 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 11 Aug 2010 00:21:52 -0500 Subject: [rspec-users] Rspec2, Autotest showing failure on all passing specs In-Reply-To: References: Message-ID: <543FB397-D07B-4926-A868-F87DBE62BD13@gmail.com> On Aug 10, 2010, at 10:45 PM, Pixel wrote: > Hey guys, > This is making me nuts, and I've run out of things to google. > I'm writing myself a little gem library, primarily for my own > education. I got a healthy start on my specs and figured I could do > myself a favor and get the specs running under autotest. It's not > working quite like I expected. My specs all pass, but autotest is > showing red instead of green. I've uploaded a screenshot of what I'm > seeing, since I don't have a specific error to report. > > http://img580.imageshack.us/img580/3396/screenshotterminal08111.png > > You can see rspec is working fine without autotest. > > I'm looking for two things here: > a) How do I get more information out of autotest and/or rspec about > this apparent error? I've tried various incantations involving > --verbose and -b and nothing seems to be getting at the information I > want. > b) How do I fix this? I'd be happy to do more googling but I don't > know what to look for anymore, various combinations of 'autotest' > 'failure' 'rspec' 'rspec2' arn't getting me the information I need and > I don't know what other keywords I can use. I've gisted some of my > configuration type files in hopes that I've just missed some simple > setup (I used jeweler to start the setup, but it's setup for rspec1 > not rspec2 so I wonder if that's where the problem originated?) You > can see those here: http://gist.github.com/518386 (I'd be happy to > include more if it's useful.) I've never seen that before. Do you have red_green installed and maybe referenced from ~/.autotest? > > Off to try and reproduce this on a fresh gemset.... > > -Cole > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users From kmandrup.github at gmail.com Wed Aug 11 02:54:53 2010 From: kmandrup.github at gmail.com (Kristian Mandrup) Date: Tue, 10 Aug 2010 23:54:53 -0700 (PDT) Subject: [rspec-users] how to place the app in the rails dir In-Reply-To: References: Message-ID: <71046d0b-c5ba-46fa-ae42-d14faf18462a@z10g2000yqb.googlegroups.com> 1) If your app name is "nice-app", make your directory like this railsprojects/nice-app 2) First update rubygems and perhaps use rvm (ruby version manager) http://railscasts.com/episodes?page=3 See railscast 200 and 201. Bundler can also be used for Rails 2 I think ;) Which version of Rails are you using? In any case, try this to download and install the missing gem locally $ gem install feedzilla Check it was installed $ gem list feedzilla To install all gems needed by your app for Rails 2, try $ rake gems:install for Rails 3 $ bundle install This should install all gems required by your application ;) Find some Rails tutorials and start from there. I learned by going through the Railscast episodes myself... Good luck! On Aug 10, 10:30?am, Aruna Chinnamuthu wrote: > Hi i am new to ROR . > I have mentioned to work on Rspec.. > i have a code given by my boss.. > I am having doubts in using them. > 1. How should i keep that code in my railsprojects directory.. Should i > keep the package given by them directly in my directory or i have to use > rails appname > 2.I actually tried by keeping the code in ?my rails dir and changes the > database.yml file > > But when i try to run script/server . > i am getting an error as > /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:31:in > `gem_original_require': no such file to load -- feedzirra > (MissingSourceFile) > > y so ?? > Pls guide me .. > -- > Posted viahttp://www.ruby-forum.com/. > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users From node.js99 at gmail.com Wed Aug 11 03:31:52 2010 From: node.js99 at gmail.com (Nadal) Date: Wed, 11 Aug 2010 00:31:52 -0700 (PDT) Subject: [rspec-users] rspec2 not working with shoulda Message-ID: <28c697cc-5992-40b1-9ab6-58a5711be15f@h32g2000yqm.googlegroups.com> I am using rails edge. I am using gem "rspec-rails", "= 2.0.0.beta. 19" . I have following code at spec/models/user_spec.rb require 'spec_helper' describe User do it { should validate_presence_of(:email) } it { should validate_presence_of(:name) } end Here is my gemfile group :development, :test do gem 'factory_girl_rails', :git => 'git://github.com/thoughtbot/ factory_girl_rails' gem 'shoulda' gem "rspec-rails", "= 2.0.0.beta.19" gem "cucumber-rails", "= 0.3.2" gem "capybara" gem "launchy" end I am getting following error message. Failure/Error: it { should validate_presence_of(:email) } undefined method `validate_presence_of' for # # ./spec/models/user_spec.rb:5 From dchelimsky at gmail.com Wed Aug 11 10:36:31 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 11 Aug 2010 09:36:31 -0500 Subject: [rspec-users] rspec2 not working with shoulda In-Reply-To: <28c697cc-5992-40b1-9ab6-58a5711be15f@h32g2000yqm.googlegroups.com> References: <28c697cc-5992-40b1-9ab6-58a5711be15f@h32g2000yqm.googlegroups.com> Message-ID: <948510DA-6013-4EEF-A5F2-1F614CA7F745@gmail.com> On Aug 11, 2010, at 2:31 AM, Nadal wrote: > I am using rails edge. I am using gem "rspec-rails", "= 2.0.0.beta. > 19" . > > I have following code at spec/models/user_spec.rb > > require 'spec_helper' > > describe User do > > it { should validate_presence_of(:email) } > > it { should validate_presence_of(:name) } > > end > > > Here is my gemfile > > group :development, :test do > gem 'factory_girl_rails', :git => 'git://github.com/thoughtbot/ > factory_girl_rails' > gem 'shoulda' > gem "rspec-rails", "= 2.0.0.beta.19" > gem "cucumber-rails", "= 0.3.2" > gem "capybara" > gem "launchy" > end > > I am getting following error message. > > > Failure/Error: it { should validate_presence_of(:email) } > undefined method `validate_presence_of' for > # > # ./spec/models/user_spec.rb:5 Sounds like shoulda is not registering itself properly with rspec-2. I'd check with the should list: http://groups.google.com/group/shoulda. HTH, David From dchelimsky at gmail.com Wed Aug 11 10:38:25 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 11 Aug 2010 09:38:25 -0500 Subject: [rspec-users] rspec2 not working with shoulda In-Reply-To: <948510DA-6013-4EEF-A5F2-1F614CA7F745@gmail.com> References: <28c697cc-5992-40b1-9ab6-58a5711be15f@h32g2000yqm.googlegroups.com> <948510DA-6013-4EEF-A5F2-1F614CA7F745@gmail.com> Message-ID: <2F32C7A1-0545-4725-AB75-6C4A36FD0FF6@gmail.com> On Aug 11, 2010, at 9:36 AM, David Chelimsky wrote: > > On Aug 11, 2010, at 2:31 AM, Nadal wrote: > >> I am using rails edge. I am using gem "rspec-rails", "= 2.0.0.beta. >> 19" . >> >> I have following code at spec/models/user_spec.rb >> >> require 'spec_helper' >> >> describe User do >> >> it { should validate_presence_of(:email) } >> >> it { should validate_presence_of(:name) } >> >> end >> >> >> Here is my gemfile >> >> group :development, :test do >> gem 'factory_girl_rails', :git => 'git://github.com/thoughtbot/ >> factory_girl_rails' >> gem 'shoulda' >> gem "rspec-rails", "= 2.0.0.beta.19" >> gem "cucumber-rails", "= 0.3.2" >> gem "capybara" >> gem "launchy" >> end >> >> I am getting following error message. >> >> >> Failure/Error: it { should validate_presence_of(:email) } >> undefined method `validate_presence_of' for >> # >> # ./spec/models/user_spec.rb:5 > > Sounds like shoulda is not registering itself properly with rspec-2. I'd check with the should list: http://groups.google.com/group/shoulda. Also - the subject line is backwards - it shoulda been "shoulda not working with rspec-2" ;) > > HTH, > David > > > From kmandrup.github at gmail.com Wed Aug 11 12:02:04 2010 From: kmandrup.github at gmail.com (Kristian Mandrup) Date: Wed, 11 Aug 2010 09:02:04 -0700 (PDT) Subject: [rspec-users] generator-spec release 0.4.8 Message-ID: <76af1dfc-1b0b-445b-b4af-7a27f662fc91@w30g2000yqw.googlegroups.com> Now with an almost complete test suite to ensure it all works as it should and to demonstrate how to use it. The DSL is better than ever! describe 'model_generator' do # include Rails model helpers for ActiveRecord # available: # Other ORM options - :mongo_mapper, :mongoid and :data_mapper # note: use_orm auto-includes the :model helper module use_orm :active_record # load helper modules and make available inside spec blocks # here the module in rails_helpers/rails_migration is included helpers :migration before :each do # define generator to test setup_generator 'model_generator' do tests Canable::Generators::ModelGenerator end # ensure clean state before each run remove_model :account end after :each do # ensure clean state after each run remove_model :account end it "should not work without an existing Account model file" do with_generator do |g| g.run_generator :account.args g.should_not generate_file :account, :model end end it "should decorate an existing Account model file with 'include Canable:Ables'" do with_generator do |g| create_model :account g.run_generator 'account'.args g.should generate_model :account do |content| content.should have_class :account do |klass| klass.should include_module 'Canable::Ables' end end end end end From cdemyanovich at gmail.com Wed Aug 11 12:28:00 2010 From: cdemyanovich at gmail.com (Craig Demyanovich) Date: Wed, 11 Aug 2010 12:28:00 -0400 Subject: [rspec-users] rspec2 not working with shoulda In-Reply-To: <2F32C7A1-0545-4725-AB75-6C4A36FD0FF6@gmail.com> References: <28c697cc-5992-40b1-9ab6-58a5711be15f@h32g2000yqm.googlegroups.com> <948510DA-6013-4EEF-A5F2-1F614CA7F745@gmail.com> <2F32C7A1-0545-4725-AB75-6C4A36FD0FF6@gmail.com> Message-ID: On Wed, Aug 11, 2010 at 10:38 AM, David Chelimsky wrote: > > Also - the subject line is backwards - it shoulda been "shoulda not working > with rspec-2" ;) It's been a long time since I tried shoulda, but I used to like to give the advice, "you shoulda used RSpec instead." ;-) Hope you get everything working, Nadal. Regards, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: From node.js99 at gmail.com Wed Aug 11 12:53:48 2010 From: node.js99 at gmail.com (Nadal) Date: Wed, 11 Aug 2010 09:53:48 -0700 (PDT) Subject: [rspec-users] rspec2 not working with shoulda In-Reply-To: References: <28c697cc-5992-40b1-9ab6-58a5711be15f@h32g2000yqm.googlegroups.com> <948510DA-6013-4EEF-A5F2-1F614CA7F745@gmail.com> <2F32C7A1-0545-4725-AB75-6C4A36FD0FF6@gmail.com> Message-ID: <102b0bc0-3a3b-428f-ba61-1fb6d8945f2c@g17g2000yqe.googlegroups.com> I posted a question on shoulda forum. It is under moderation so I don't have a link yet. To the people who do not use shoulda: How would you write a test for above case. I assume it would require set up a subject, set nil value, and then see if there is an error message. I still think that for such cases should macro is succint and does it job well unless I am missing some new feature of rspec2. Thanks On Aug 11, 12:28?pm, Craig Demyanovich wrote: > On Wed, Aug 11, 2010 at 10:38 AM, David Chelimsky wrote: > > > > > Also - the subject line is backwards - it shoulda been "shoulda not working > > with rspec-2" ;) > > It's been a long time since I tried shoulda, but I used to like to give the > advice, "you shoulda used RSpec instead." ;-) > > Hope you get everything working, Nadal. > > Regards, > Craig > > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users From cdemyanovich at gmail.com Wed Aug 11 13:29:13 2010 From: cdemyanovich at gmail.com (Craig Demyanovich) Date: Wed, 11 Aug 2010 13:29:13 -0400 Subject: [rspec-users] rspec2 not working with shoulda In-Reply-To: <102b0bc0-3a3b-428f-ba61-1fb6d8945f2c@g17g2000yqe.googlegroups.com> References: <28c697cc-5992-40b1-9ab6-58a5711be15f@h32g2000yqm.googlegroups.com> <948510DA-6013-4EEF-A5F2-1F614CA7F745@gmail.com> <2F32C7A1-0545-4725-AB75-6C4A36FD0FF6@gmail.com> <102b0bc0-3a3b-428f-ba61-1fb6d8945f2c@g17g2000yqe.googlegroups.com> Message-ID: On Wed, Aug 11, 2010 at 12:53 PM, Nadal wrote: > I posted a question on shoulda forum. It is under moderation so I > don't have a link yet. > > To the people who do not use shoulda: How would you write a test for > above case. I assume it would require set up a subject, set nil value, > and then see if there is an error message. I still think that for such > cases should macro is succint and does it job well unless I am missing > some new feature of rspec2. I don't yet use RSpec 2, but I don't think you're missing anything. Shoulda may very well be a good fit for these kinds of examples. Since you asked, here's how I currently write examples like the ones you posted. require 'spec_helper' describe User, "being valid" do it "requires an email" do user = User.new(:email => nil) user.should_not be_valid user.should have(1).error_on(:email) end it "requires a name" do user = User.new(:name => nil) user.should_not be_valid user.should have(1).error_on(:name) end end Regards, Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: From phillipkoebbe at gmail.com Wed Aug 11 14:21:43 2010 From: phillipkoebbe at gmail.com (Phillip Koebbe) Date: Wed, 11 Aug 2010 13:21:43 -0500 Subject: [rspec-users] rspec2 not working with shoulda In-Reply-To: References: <28c697cc-5992-40b1-9ab6-58a5711be15f@h32g2000yqm.googlegroups.com> <948510DA-6013-4EEF-A5F2-1F614CA7F745@gmail.com> <2F32C7A1-0545-4725-AB75-6C4A36FD0FF6@gmail.com> <102b0bc0-3a3b-428f-ba61-1fb6d8945f2c@g17g2000yqe.googlegroups.com> Message-ID: <4C62EA37.9020705@gmail.com> On 2010-08-11 12:29 PM, Craig Demyanovich wrote: > On Wed, Aug 11, 2010 at 12:53 PM, Nadal > wrote: > > I posted a question on shoulda forum. It is under moderation so I > don't have a link yet. > > To the people who do not use shoulda: How would you write a test for > above case. I assume it would require set up a subject, set nil value, > and then see if there is an error message. I still think that for such > cases should macro is succint and does it job well unless I am missing > some new feature of rspec2. > > > I don't yet use RSpec 2, but I don't think you're missing anything. > Shoulda may very well be a good fit for these kinds of examples. > > Since you asked, here's how I currently write examples like the ones > you posted. > > require 'spec_helper' > > describe User, "being valid" do > it "requires an email" do > user = User.new(:email => nil) > user.should_not be_valid > user.should have(1).error_on(:email) > end > it "requires a name" do > user = User.new(:name => nil) > user.should_not be_valid > user.should have(1).error_on(:name) > end > end > > Regards, > Craig That's exactly what I used to do, also, until I switched to Remarkable. Now it's: before :each do @user = User.create(valid_user_hash) end should_validate_presence_of :first_name should_validate_presence_of :last_name should_validate_presence_of :email should_validate_uniqueness_of :email, :case_sensitive => false should_validate_format_of_email One thing I have come to appreciate about this is being able to copy the should_* statements to my model and, using TextMate's column editing mode, remove the 'should_' and add an 's' at the end of 'validate' and I'm done. For all of the validations that Remarkable supports, the same options are supported as well. That's actually why I switch from Shoulda to Remarkable a year or so ago (things might have changed in Shoulda by now, though): Not all validation options were supported in Shoulda. Peace, Phillip From dhf0820 at gmail.com Wed Aug 11 14:44:32 2010 From: dhf0820 at gmail.com (Don French) Date: Wed, 11 Aug 2010 11:44:32 -0700 (PDT) Subject: [rspec-users] Autotest does not start In-Reply-To: References: Message-ID: Any help on this. I think I have read all posts related to autotest but still do not have the answer. Is there something that works better with Rspec that autotest? Don French On Aug 10, 4:24?pm, Don French wrote: > I have a non rails app using rspec2. ?I created the autotest/ > discover.rb and put in it Autotest.add_discovery {"rspec2"}. ?When I > run under bundler I get - > > loading autotest/rspec2 > and a prompt back > > When standalone I get: > > loading autotest/rspec2 > style: Rspec2 > > and a prompt. Any ideasas to the problem. I am sure I am missing > something because there is no rails involved. > > Mahalo > Don French > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users From ashley.moran at patchspace.co.uk Wed Aug 11 14:49:36 2010 From: ashley.moran at patchspace.co.uk (Ashley Moran) Date: Wed, 11 Aug 2010 19:49:36 +0100 Subject: [rspec-users] Autotest does not start In-Reply-To: References: Message-ID: <7D83AF96-AFF7-437A-9CF2-69437D51A663@patchspace.co.uk> On 11 Aug 2010, at 19:44, Don French wrote: > Any help on this. I think I have read all posts related to autotest > but still do not have the answer. Is there something that works better > with Rspec that autotest? When you say "and a prompt (back)" ... do you mean autotest exits in both situations and doesn't run any tests? (I'm running autotest with RSpec 2 fine, BTW.) Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran From thecatwasnot at gmail.com Wed Aug 11 15:48:46 2010 From: thecatwasnot at gmail.com (Pixel) Date: Wed, 11 Aug 2010 14:48:46 -0500 Subject: [rspec-users] Rspec2, Autotest showing failure on all passing specs In-Reply-To: <543FB397-D07B-4926-A868-F87DBE62BD13@gmail.com> References: <543FB397-D07B-4926-A868-F87DBE62BD13@gmail.com> Message-ID: On Wed, Aug 11, 2010 at 12:21 AM, David Chelimsky wrote: > I've never seen that before. Do you have red_green installed and maybe referenced from ~/.autotest? > >> >> Off to try and reproduce this on a fresh gemset.... >> >> -Cole Hey David, It appears at the moment that this is coming from a gem called autotest-notification that does a bit of magic with the ~/.autotest file to add itself. There is an open issue already and it doesn't seem like there is anything hinky about my setup. My current suspicion is that it's because this autotest-notification gem can't play nicely with a) latest autotest b) rspec2 c)ruby 1.9.*. I'm poking around in it right now to try to figure out if it's something I can fix. Thanks for your response, for whatever reason I thought that bit of output was coming from autotest when it's really coming from this other gem. Thanks. -Cole From myron.marston at gmail.com Wed Aug 11 16:05:47 2010 From: myron.marston at gmail.com (Myron Marston) Date: Wed, 11 Aug 2010 13:05:47 -0700 (PDT) Subject: [rspec-users] Name collision - how would you handle this? In-Reply-To: <3D0F0C84-8692-4346-A97C-CFC6AFEF5599@gmail.com> References: <958F356A-6B8F-49FF-B89E-C4557E943B2E@gmail.com> <13E563D1-9C62-4C75-A825-7D57F8C166DE@mattwynne.net> <6972E490-0BCD-4225-A9B4-BFA06ECA972A@mattwynne.net> <3D0F0C84-8692-4346-A97C-CFC6AFEF5599@gmail.com> Message-ID: <68723cef-41b2-4ea8-9316-3b666b23cce8@x24g2000pro.googlegroups.com> Sorry it's taken me so long to respond--I have considerably less time on weekdays than the weekend to take care of things like this. > Yehuda Katz made a similar suggestion to me, referencing some code from merb:http://github.com/merb/merb/blob/master/merb-core/lib/merb-core/contr... > > Merb also has an override! method that end users can use to override the registered reserved methods, which I agree would be a necessary part of this. The idea being that any user that does that does so explicitly and knowingly. Merb's implementation is very similar to what I had in mind. It's nice to see I'm not in left field with my idea :). I agree that having something like override! is important, although I think I slightly prefer an API like this: allow_reserved_overrides do def reserved_method end end Or maybe I like blocks too much... > The blacklist comment probably wouldn't work for upstream libs like Rails, Test::Unit or MiniUnit. It would be up to RSpec to define those lists. But maybe that's an acceptable tradeoff. WDYT? RSpec is pretty high-profile in the Ruby community, so we could hopefully get most libraries to add their reserved methods using something like: if defined?(RSpec::Core.add_reserved_methods) RSpec::Core.add_reserved_methods :foo, :bar, :bazz end As far as Rails goes, rspec-rails seems like a natural point to register these reserved methods. For libraries that are distributed with ruby like Test::Unit, I think it's acceptable to register their reserved methods in rspec-core itself. What do others think of this idea? I'm willing to take a stab at implementing this if there is support for it. Myron From dchelimsky at gmail.com Wed Aug 11 16:07:59 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 11 Aug 2010 15:07:59 -0500 Subject: [rspec-users] Rspec2, Autotest showing failure on all passing specs In-Reply-To: References: <543FB397-D07B-4926-A868-F87DBE62BD13@gmail.com> Message-ID: <3354E5F9-F020-46E6-B7C2-A547BD71BE58@gmail.com> On Aug 11, 2010, at 2:48 PM, Pixel wrote: > On Wed, Aug 11, 2010 at 12:21 AM, David Chelimsky wrote: >> I've never seen that before. Do you have red_green installed and maybe referenced from ~/.autotest? >> >>> >>> Off to try and reproduce this on a fresh gemset.... >>> >>> -Cole > > Hey David, > It appears at the moment that this is coming from a gem called > autotest-notification that does a bit of magic with the ~/.autotest > file to add itself. There is an open issue already and it doesn't > seem like there is anything hinky about my setup. My current > suspicion is that it's because this autotest-notification gem can't > play nicely with a) latest autotest b) rspec2 c)ruby 1.9.*. I'm > poking around in it right now to try to figure out if it's something I > can fix. > > Thanks for your response, for whatever reason I thought that bit of > output was coming from autotest when it's really coming from this > other gem. Glad you found it, and thanks for following up. Hopefully you'll save the next person to experience this a few cycles. Cheers, David > Thanks. > -Cole From dhf0820 at gmail.com Wed Aug 11 17:54:06 2010 From: dhf0820 at gmail.com (Don French) Date: Wed, 11 Aug 2010 14:54:06 -0700 (PDT) Subject: [rspec-users] Autotest does not start In-Reply-To: <7D83AF96-AFF7-437A-9CF2-69437D51A663@patchspace.co.uk> References: <7D83AF96-AFF7-437A-9CF2-69437D51A663@patchspace.co.uk> Message-ID: <5fa23942-0d23-48a2-8649-cf85a97a40ab@k1g2000prl.googlegroups.com> That is correct. No tests are run. Just get the OS command prompt back. Don French On Aug 11, 8:49?am, Ashley Moran wrote: > On 11 Aug 2010, at 19:44, Don French wrote: > > > Any help on this. I think I have read all posts related to autotest > > but still do not have the answer. Is there something that works better > > with Rspec that autotest? > > When you say "and a prompt (back)" ... do you mean autotest exits in both situations and doesn't run any tests? > > (I'm running autotest with RSpec 2 fine, BTW.) > > Ash > > --http://www.patchspace.co.uk/http://www.linkedin.com/in/ashleymoran > > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users From dchelimsky at gmail.com Wed Aug 11 19:14:31 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 11 Aug 2010 18:14:31 -0500 Subject: [rspec-users] Autotest does not start In-Reply-To: <5fa23942-0d23-48a2-8649-cf85a97a40ab@k1g2000prl.googlegroups.com> References: <7D83AF96-AFF7-437A-9CF2-69437D51A663@patchspace.co.uk> <5fa23942-0d23-48a2-8649-cf85a97a40ab@k1g2000prl.googlegroups.com> Message-ID: On Aug 11, 2010, at 4:54 PM, Don French wrote: > That is correct. No tests are run. Just get the OS command prompt > back. You said in an earlier post that this happens whether you run this under bundler or not. What, precisely, are the commands you're using? > Don French > > > On Aug 11, 8:49 am, Ashley Moran > wrote: >> On 11 Aug 2010, at 19:44, Don French wrote: >> >>> Any help on this. I think I have read all posts related to autotest >>> but still do not have the answer. Is there something that works better >>> with Rspec that autotest? >> >> When you say "and a prompt (back)" ... do you mean autotest exits in both situations and doesn't run any tests? >> >> (I'm running autotest with RSpec 2 fine, BTW.) >> >> Ash >> >> --http://www.patchspace.co.uk/http://www.linkedin.com/in/ashleymoran >> >> _______________________________________________ >> rspec-users mailing list >> rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users From dchelimsky at gmail.com Wed Aug 11 23:30:36 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 11 Aug 2010 22:30:36 -0500 Subject: [rspec-users] Name collision - how would you handle this? In-Reply-To: <68723cef-41b2-4ea8-9316-3b666b23cce8@x24g2000pro.googlegroups.com> References: <958F356A-6B8F-49FF-B89E-C4557E943B2E@gmail.com> <13E563D1-9C62-4C75-A825-7D57F8C166DE@mattwynne.net> <6972E490-0BCD-4225-A9B4-BFA06ECA972A@mattwynne.net> <3D0F0C84-8692-4346-A97C-CFC6AFEF5599@gmail.com> <68723cef-41b2-4ea8-9316-3b666b23cce8@x24g2000pro.googlegroups.com> Message-ID: <83B6D23A-0CF6-4813-8A4C-BDCC9690100E@gmail.com> On Aug 11, 2010, at 3:05 PM, Myron Marston wrote: > Sorry it's taken me so long to respond--I have considerably less time > on weekdays than the weekend to take care of things like this. > >> Yehuda Katz made a similar suggestion to me, referencing some code from merb:http://github.com/merb/merb/blob/master/merb-core/lib/merb-core/contr... >> >> Merb also has an override! method that end users can use to override the registered reserved methods, which I agree would be a necessary part of this. The idea being that any user that does that does so explicitly and knowingly. > > Merb's implementation is very similar to what I had in mind. It's > nice to see I'm not in left field with my idea :). > > I agree that having something like override! is important, although I > think I slightly prefer an API like this: > > allow_reserved_overrides do > def reserved_method > end > end > > Or maybe I like blocks too much... > >> The blacklist comment probably wouldn't work for upstream libs like Rails, Test::Unit or MiniUnit. It would be up to RSpec to define those lists. But maybe that's an acceptable tradeoff. WDYT? > > RSpec is pretty high-profile in the Ruby community, so we could > hopefully get most libraries to add their reserved methods using > something like: > > if defined?(RSpec::Core.add_reserved_methods) > RSpec::Core.add_reserved_methods :foo, :bar, :bazz > end > > As far as Rails goes, rspec-rails seems like a natural point to > register these reserved methods. For libraries that are distributed > with ruby like Test::Unit, I think it's acceptable to register their > reserved methods in rspec-core itself. I think they should all be registered in the same place, in rspec-core. Or are you saying that rspec-rails would take the responsibility of registering the names for rspec-rails, rails, test/unit and minitest? That makes sense to me, as long as they're all using RSpec::Core::register_reserved_name (or whatever). > What do others think of this idea? I'm willing to take a stab at > implementing this if there is support for it. I'm still not sold on this idea yet. Seems like a lot of complexity for not much benefit. I've already taken care of the message issue by encapsulating the assertion libs in a separate scope. Anybody else have opinions on this? > > Myron > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users From dhf0820 at gmail.com Thu Aug 12 03:27:42 2010 From: dhf0820 at gmail.com (Don French) Date: Thu, 12 Aug 2010 00:27:42 -0700 (PDT) Subject: [rspec-users] Autotest does not start In-Reply-To: References: <7D83AF96-AFF7-437A-9CF2-69437D51A663@patchspace.co.uk> <5fa23942-0d23-48a2-8649-cf85a97a40ab@k1g2000prl.googlegroups.com> Message-ID: <47718594-06f2-45d8-bf1e-c403e49cfbe0@x20g2000pro.googlegroups.com> under bundler bundle exec autotest standalone autotest both within the project directory and there is a spec subdirectory with the spec in them. On Aug 11, 1:14?pm, David Chelimsky wrote: > On Aug 11, 2010, at 4:54 PM, Don French wrote: > > > That is correct. No tests are run. Just get the OS command prompt > > back. > > You said in an earlier post that this happens whether you run this under bundler or not. What, precisely, are the commands you're using? > > > > > > > Don French > > > On Aug 11, 8:49 am, Ashley Moran > > wrote: > >> On 11 Aug 2010, at 19:44, Don French wrote: > > >>> Any help on this. I think I have read all posts related to autotest > >>> but still do not have the answer. Is there something that works better > >>> with Rspec that autotest? > > >> When you say "and a prompt (back)" ... do you mean autotest exits in both situations and doesn't run any tests? > > >> (I'm running autotest with RSpec 2 fine, BTW.) > > >> Ash > > >> --http://www.patchspace.co.uk/http://www.linkedin.com/in/ashleymoran > > >> _______________________________________________ > >> rspec-users mailing list > >> rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users > > _______________________________________________ > > rspec-users mailing list > > rspec-us... at rubyforge.org > >http://rubyforge.org/mailman/listinfo/rspec-users > > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users From kmandrup.github at gmail.com Thu Aug 12 03:55:10 2010 From: kmandrup.github at gmail.com (Kristian Mandrup) Date: Thu, 12 Aug 2010 00:55:10 -0700 (PDT) Subject: [rspec-users] how to place the app in the rails dir In-Reply-To: <71046d0b-c5ba-46fa-ae42-d14faf18462a@z10g2000yqb.googlegroups.com> References: <71046d0b-c5ba-46fa-ae42-d14faf18462a@z10g2000yqb.googlegroups.com> Message-ID: <87d9582a-cf54-4716-a804-e8d8510f7e3d@l14g2000yql.googlegroups.com> To learn Rails, checkout: http://railsnotes.com/rails-3/ From ashley.moran at patchspace.co.uk Thu Aug 12 14:21:36 2010 From: ashley.moran at patchspace.co.uk (Ashley Moran) Date: Thu, 12 Aug 2010 19:21:36 +0100 Subject: [rspec-users] Autotest does not start In-Reply-To: <47718594-06f2-45d8-bf1e-c403e49cfbe0@x20g2000pro.googlegroups.com> References: <7D83AF96-AFF7-437A-9CF2-69437D51A663@patchspace.co.uk> <5fa23942-0d23-48a2-8649-cf85a97a40ab@k1g2000prl.googlegroups.com> <47718594-06f2-45d8-bf1e-c403e49cfbe0@x20g2000pro.googlegroups.com> Message-ID: <6D126106-0074-4676-A40F-D15C8DAE2FA1@patchspace.co.uk> On 12 Aug 2010, at 08:27, Don French wrote: > under bundler bundle exec autotest standalone autotest both within > the project directory and there is a spec subdirectory with the spec > in them. What happens when you run `rspec spec`? What is in your spec_helper.rb file? What is the output of `find spec`? That's all I can think of asking right now... -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran From ashley.moran at patchspace.co.uk Thu Aug 12 14:24:23 2010 From: ashley.moran at patchspace.co.uk (Ashley Moran) Date: Thu, 12 Aug 2010 19:24:23 +0100 Subject: [rspec-users] Name collision - how would you handle this? In-Reply-To: <83B6D23A-0CF6-4813-8A4C-BDCC9690100E@gmail.com> References: <958F356A-6B8F-49FF-B89E-C4557E943B2E@gmail.com> <13E563D1-9C62-4C75-A825-7D57F8C166DE@mattwynne.net> <6972E490-0BCD-4225-A9B4-BFA06ECA972A@mattwynne.net> <3D0F0C84-8692-4346-A97C-CFC6AFEF5599@gmail.com> <68723cef-41b2-4ea8-9316-3b666b23cce8@x24g2000pro.googlegroups.com> <83B6D23A-0CF6-4813-8A4C-BDCC9690100E@gmail.com> Message-ID: On 12 Aug 2010, at 04:30, David Chelimsky wrote: > I think they should all be registered in the same place, in rspec-core. Or are you saying that rspec-rails would take the responsibility of registering the names for rspec-rails, rails, test/unit and minitest? That makes sense to me, as long as they're all using RSpec::Core::register_reserved_name (or whatever). > >> What do others think of this idea? I'm willing to take a stab at >> implementing this if there is support for it. > > I'm still not sold on this idea yet. Seems like a lot of complexity for not much benefit. I've already taken care of the message issue by encapsulating the assertion libs in a separate scope. > > Anybody else have opinions on this? The idea sounds interesting, but sounds like it could lead to a nasty dependency down the line. Is there any way of doing the core of this as an external gem, that all interested projects could use? I'm only following the edge of this thread, but by dependency radar went off - it's a bit oversensitive. -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran From dhf0820 at gmail.com Thu Aug 12 16:08:14 2010 From: dhf0820 at gmail.com (Don French) Date: Thu, 12 Aug 2010 13:08:14 -0700 (PDT) Subject: [rspec-users] Autotest does not start In-Reply-To: <6D126106-0074-4676-A40F-D15C8DAE2FA1@patchspace.co.uk> References: <7D83AF96-AFF7-437A-9CF2-69437D51A663@patchspace.co.uk> <5fa23942-0d23-48a2-8649-cf85a97a40ab@k1g2000prl.googlegroups.com> <47718594-06f2-45d8-bf1e-c403e49cfbe0@x20g2000pro.googlegroups.com> <6D126106-0074-4676-A40F-D15C8DAE2FA1@patchspace.co.uk> Message-ID: <0576a69e-8f9d-4982-aeb0-7025abb1ab49@q40g2000prg.googlegroups.com> rspec spec works fine and provides test results. The helper file does not have anything in it. It had the the old #begin # require 'spec' #rescue LoadError # require 'rubygems' unless Config['NO_RUBYGEMS'] # gem 'rspec' # require 'spec' #end from rspec 1.3.0 Now it is empty. This project was generated via newgem. I want to upgrade to rspec2 and ruby 1.9.2. Doing it in stages currently 1.9.1. Don French On Aug 12, 8:21?am, Ashley Moran wrote: > On 12 Aug 2010, at 08:27, Don French wrote: > > > under bundler bundle exec autotest ?standalone autotest both within > > the project directory and there is a spec subdirectory with the spec > > in them. > > What happens when you run `rspec spec`? > > What is in your spec_helper.rb file? > > What is the output of `find spec`? > > That's all I can think of asking right now... > > --http://www.patchspace.co.uk/http://www.linkedin.com/in/ashleymoran > > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users From dhf0820 at gmail.com Thu Aug 12 16:08:44 2010 From: dhf0820 at gmail.com (Don French) Date: Thu, 12 Aug 2010 13:08:44 -0700 (PDT) Subject: [rspec-users] Autotest does not start In-Reply-To: <6D126106-0074-4676-A40F-D15C8DAE2FA1@patchspace.co.uk> References: <7D83AF96-AFF7-437A-9CF2-69437D51A663@patchspace.co.uk> <5fa23942-0d23-48a2-8649-cf85a97a40ab@k1g2000prl.googlegroups.com> <47718594-06f2-45d8-bf1e-c403e49cfbe0@x20g2000pro.googlegroups.com> <6D126106-0074-4676-A40F-D15C8DAE2FA1@patchspace.co.uk> Message-ID: <6248c7ce-d31e-4966-9200-06fdf7cf5a95@i18g2000pro.googlegroups.com> The helper file does not have anything in it as of right now. It had the the old #begin # require 'spec' #rescue LoadError # require 'rubygems' unless Config['NO_RUBYGEMS'] # gem 'rspec' # require 'spec' #end from rspec 1.3.0 Now it is empty. This project was generated via newgem. I want to upgrade to rspec2 and ruby 1.9.2. Doing it in stages currently 1.9.1. Don French On Aug 12, 8:21?am, Ashley Moran wrote: > On 12 Aug 2010, at 08:27, Don French wrote: > > > under bundler bundle exec autotest ?standalone autotest both within > > the project directory and there is a spec subdirectory with the spec > > in them. > > What happens when you run `rspec spec`? > > What is in your spec_helper.rb file? > > What is the output of `find spec`? > > That's all I can think of asking right now... > > --http://www.patchspace.co.uk/http://www.linkedin.com/in/ashleymoran > > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users From dchelimsky at gmail.com Thu Aug 12 16:13:52 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 12 Aug 2010 15:13:52 -0500 Subject: [rspec-users] Autotest does not start In-Reply-To: <6248c7ce-d31e-4966-9200-06fdf7cf5a95@i18g2000pro.googlegroups.com> References: <7D83AF96-AFF7-437A-9CF2-69437D51A663@patchspace.co.uk> <5fa23942-0d23-48a2-8649-cf85a97a40ab@k1g2000prl.googlegroups.com> <47718594-06f2-45d8-bf1e-c403e49cfbe0@x20g2000pro.googlegroups.com> <6D126106-0074-4676-A40F-D15C8DAE2FA1@patchspace.co.uk> <6248c7ce-d31e-4966-9200-06fdf7cf5a95@i18g2000pro.googlegroups.com> Message-ID: <724671BA-CD87-4BD4-BC48-88DC1545C33E@gmail.com> On Aug 12, 2010, at 3:08 PM, Don French wrote: > The helper file does not have anything in it as of right now. It had > the the old > #begin > # require 'spec' > #rescue LoadError > # require 'rubygems' unless Config['NO_RUBYGEMS'] > # gem 'rspec' > # require 'spec' > #end > from rspec 1.3.0 > > Now it is empty. I can't find it, but I could swear there was a bug report about empty spec files causing rspec to not output anything. Try putting some code in there and see what happens. > This project was generated via newgem. > > I want to upgrade to rspec2 and ruby 1.9.2. Doing it in stages > currently 1.9.1. > > Don French > > On Aug 12, 8:21 am, Ashley Moran > wrote: >> On 12 Aug 2010, at 08:27, Don French wrote: >> >>> under bundler bundle exec autotest standalone autotest both within >>> the project directory and there is a spec subdirectory with the spec >>> in them. >> >> What happens when you run `rspec spec`? >> >> What is in your spec_helper.rb file? >> >> What is the output of `find spec`? >> >> That's all I can think of asking right now... >> >> --http://www.patchspace.co.uk/http://www.linkedin.com/in/ashleymoran >> >> _______________________________________________ >> rspec-users mailing list >> rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users From dhf0820 at gmail.com Thu Aug 12 16:48:56 2010 From: dhf0820 at gmail.com (Don French) Date: Thu, 12 Aug 2010 13:48:56 -0700 (PDT) Subject: [rspec-users] Autotest does not start In-Reply-To: <724671BA-CD87-4BD4-BC48-88DC1545C33E@gmail.com> References: <7D83AF96-AFF7-437A-9CF2-69437D51A663@patchspace.co.uk> <5fa23942-0d23-48a2-8649-cf85a97a40ab@k1g2000prl.googlegroups.com> <47718594-06f2-45d8-bf1e-c403e49cfbe0@x20g2000pro.googlegroups.com> <6D126106-0074-4676-A40F-D15C8DAE2FA1@patchspace.co.uk> <6248c7ce-d31e-4966-9200-06fdf7cf5a95@i18g2000pro.googlegroups.com> <724671BA-CD87-4BD4-BC48-88DC1545C33E@gmail.com> Message-ID: put in $:.unshift(File.dirname(__FILE__) + '/../lib') require 'reader' and get the same thing dhf On Aug 12, 10:13?am, David Chelimsky wrote: > On Aug 12, 2010, at 3:08 PM, Don French wrote: > > > The helper file does not have anything in it as of right now. It had > > the the old > > ?#begin > > # ?require 'spec' > > #rescue LoadError > > # ?require 'rubygems' unless Config['NO_RUBYGEMS'] > > # ?gem 'rspec' > > # ?require 'spec' > > #end > > from rspec 1.3.0 > > > Now it is empty. > > I can't find it, but I could swear there was a bug report about empty spec files causing rspec to not output anything. Try putting some code in there and see what happens. > > > > > > > This project was generated via newgem. > > > I want to upgrade to rspec2 and ruby 1.9.2. ?Doing it in stages > > currently 1.9.1. > > > Don French > > > On Aug 12, 8:21 am, Ashley Moran > > wrote: > >> On 12 Aug 2010, at 08:27, Don French wrote: > > >>> under bundler bundle exec autotest ?standalone autotest both within > >>> the project directory and there is a spec subdirectory with the spec > >>> in them. > > >> What happens when you run `rspec spec`? > > >> What is in your spec_helper.rb file? > > >> What is the output of `find spec`? > > >> That's all I can think of asking right now... > > >> --http://www.patchspace.co.uk/http://www.linkedin.com/in/ashleymoran > > >> _______________________________________________ > >> rspec-users mailing list > >> rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users > > _______________________________________________ > > rspec-users mailing list > > rspec-us... at rubyforge.org > >http://rubyforge.org/mailman/listinfo/rspec-users > > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users From dhf0820 at gmail.com Thu Aug 12 17:01:12 2010 From: dhf0820 at gmail.com (Don French) Date: Thu, 12 Aug 2010 14:01:12 -0700 (PDT) Subject: [rspec-users] Autotest does not start In-Reply-To: <724671BA-CD87-4BD4-BC48-88DC1545C33E@gmail.com> References: <7D83AF96-AFF7-437A-9CF2-69437D51A663@patchspace.co.uk> <5fa23942-0d23-48a2-8649-cf85a97a40ab@k1g2000prl.googlegroups.com> <47718594-06f2-45d8-bf1e-c403e49cfbe0@x20g2000pro.googlegroups.com> <6D126106-0074-4676-A40F-D15C8DAE2FA1@patchspace.co.uk> <6248c7ce-d31e-4966-9200-06fdf7cf5a95@i18g2000pro.googlegroups.com> <724671BA-CD87-4BD4-BC48-88DC1545C33E@gmail.com> Message-ID: <852920c7-61b4-42cf-bf7f-d875bb68de5a@u4g2000prn.googlegroups.com> I put in: $:.unshift(File.dirname(__FILE__) + '/../lib') require 'reader' and it still does nothing. dhf On Aug 12, 10:13?am, David Chelimsky wrote: > On Aug 12, 2010, at 3:08 PM, Don French wrote: > > > The helper file does not have anything in it as of right now. It had > > the the old > > ?#begin > > # ?require 'spec' > > #rescue LoadError > > # ?require 'rubygems' unless Config['NO_RUBYGEMS'] > > # ?gem 'rspec' > > # ?require 'spec' > > #end > > from rspec 1.3.0 > > > Now it is empty. > > I can't find it, but I could swear there was a bug report about empty spec files causing rspec to not output anything. Try putting some code in there and see what happens. > > > > > > > This project was generated via newgem. > > > I want to upgrade to rspec2 and ruby 1.9.2. ?Doing it in stages > > currently 1.9.1. > > > Don French > > > On Aug 12, 8:21 am, Ashley Moran > > wrote: > >> On 12 Aug 2010, at 08:27, Don French wrote: > > >>> under bundler bundle exec autotest ?standalone autotest both within > >>> the project directory and there is a spec subdirectory with the spec > >>> in them. > > >> What happens when you run `rspec spec`? > > >> What is in your spec_helper.rb file? > > >> What is the output of `find spec`? > > >> That's all I can think of asking right now... > > >> --http://www.patchspace.co.uk/http://www.linkedin.com/in/ashleymoran > > >> _______________________________________________ > >> rspec-users mailing list > >> rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users > > _______________________________________________ > > rspec-users mailing list > > rspec-us... at rubyforge.org > >http://rubyforge.org/mailman/listinfo/rspec-users > > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users From dhf0820 at gmail.com Thu Aug 12 17:02:53 2010 From: dhf0820 at gmail.com (Don French) Date: Thu, 12 Aug 2010 14:02:53 -0700 (PDT) Subject: [rspec-users] Autotest does not start In-Reply-To: References: <7D83AF96-AFF7-437A-9CF2-69437D51A663@patchspace.co.uk> <5fa23942-0d23-48a2-8649-cf85a97a40ab@k1g2000prl.googlegroups.com> <47718594-06f2-45d8-bf1e-c403e49cfbe0@x20g2000pro.googlegroups.com> <6D126106-0074-4676-A40F-D15C8DAE2FA1@patchspace.co.uk> <6248c7ce-d31e-4966-9200-06fdf7cf5a95@i18g2000pro.googlegroups.com> <724671BA-CD87-4BD4-BC48-88DC1545C33E@gmail.com> Message-ID: There are lots of spec files. I can run them using rspec spec and everything is great. just the autotest does not work. Don French On Aug 12, 10:48?am, Don French wrote: > put in > $:.unshift(File.dirname(__FILE__) + '/../lib') > require 'reader' > and get the same thing > > dhf > > On Aug 12, 10:13?am, David Chelimsky wrote: > > > > > On Aug 12, 2010, at 3:08 PM, Don French wrote: > > > > The helper file does not have anything in it as of right now. It had > > > the the old > > > ?#begin > > > # ?require 'spec' > > > #rescue LoadError > > > # ?require 'rubygems' unless Config['NO_RUBYGEMS'] > > > # ?gem 'rspec' > > > # ?require 'spec' > > > #end > > > from rspec 1.3.0 > > > > Now it is empty. > > > I can't find it, but I could swear there was a bug report about empty spec files causing rspec to not output anything. Try putting some code in there and see what happens. > > > > This project was generated via newgem. > > > > I want to upgrade to rspec2 and ruby 1.9.2. ?Doing it in stages > > > currently 1.9.1. > > > > Don French > > > > On Aug 12, 8:21 am, Ashley Moran > > > wrote: > > >> On 12 Aug 2010, at 08:27, Don French wrote: > > > >>> under bundler bundle exec autotest ?standalone autotest both within > > >>> the project directory and there is a spec subdirectory with the spec > > >>> in them. > > > >> What happens when you run `rspec spec`? > > > >> What is in your spec_helper.rb file? > > > >> What is the output of `find spec`? > > > >> That's all I can think of asking right now... > > > >> --http://www.patchspace.co.uk/http://www.linkedin.com/in/ashleymoran > > > >> _______________________________________________ > > >> rspec-users mailing list > > >> rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users > > > _______________________________________________ > > > rspec-users mailing list > > > rspec-us... at rubyforge.org > > >http://rubyforge.org/mailman/listinfo/rspec-users > > > _______________________________________________ > > rspec-users mailing list > > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users > > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users From dchelimsky at gmail.com Thu Aug 12 17:32:37 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 12 Aug 2010 16:32:37 -0500 Subject: [rspec-users] Autotest does not start In-Reply-To: References: <7D83AF96-AFF7-437A-9CF2-69437D51A663@patchspace.co.uk> <5fa23942-0d23-48a2-8649-cf85a97a40ab@k1g2000prl.googlegroups.com> <47718594-06f2-45d8-bf1e-c403e49cfbe0@x20g2000pro.googlegroups.com> <6D126106-0074-4676-A40F-D15C8DAE2FA1@patchspace.co.uk> <6248c7ce-d31e-4966-9200-06fdf7cf5a95@i18g2000pro.googlegroups.com> <724671BA-CD87-4BD4-BC48-88DC1545C33E@gmail.com> Message-ID: <4092E882-6E69-4737-9725-D75D4C809BA8@gmail.com> On Aug 12, 2010, at 4:02 PM, Don French wrote: > There are lots of spec files. I can run them using rspec spec and > everything is great. just the autotest does not work. > Don French Did you create autotest/discover.rb? http://blog.davidchelimsky.net/2010/03/15/rspec-2-and-autotest/ > > On Aug 12, 10:48 am, Don French wrote: >> put in >> $:.unshift(File.dirname(__FILE__) + '/../lib') >> require 'reader' >> and get the same thing >> >> dhf >> >> On Aug 12, 10:13 am, David Chelimsky wrote: >> >> >> >>> On Aug 12, 2010, at 3:08 PM, Don French wrote: >> >>>> The helper file does not have anything in it as of right now. It had >>>> the the old >>>> #begin >>>> # require 'spec' >>>> #rescue LoadError >>>> # require 'rubygems' unless Config['NO_RUBYGEMS'] >>>> # gem 'rspec' >>>> # require 'spec' >>>> #end >>>> from rspec 1.3.0 >> >>>> Now it is empty. >> >>> I can't find it, but I could swear there was a bug report about empty spec files causing rspec to not output anything. Try putting some code in there and see what happens. >> >>>> This project was generated via newgem. >> >>>> I want to upgrade to rspec2 and ruby 1.9.2. Doing it in stages >>>> currently 1.9.1. >> >>>> Don French >> >>>> On Aug 12, 8:21 am, Ashley Moran >>>> wrote: >>>>> On 12 Aug 2010, at 08:27, Don French wrote: >> >>>>>> under bundler bundle exec autotest standalone autotest both within >>>>>> the project directory and there is a spec subdirectory with the spec >>>>>> in them. >> >>>>> What happens when you run `rspec spec`? >> >>>>> What is in your spec_helper.rb file? >> >>>>> What is the output of `find spec`? >> >>>>> That's all I can think of asking right now... >> >>>>> --http://www.patchspace.co.uk/http://www.linkedin.com/in/ashleymoran >> >>>>> _______________________________________________ >>>>> rspec-users mailing list >>>>> rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users >>>> _______________________________________________ >>>> rspec-users mailing list >>>> rspec-us... at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/rspec-users >> >>> _______________________________________________ >>> rspec-users mailing list >>> rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users >> >> _______________________________________________ >> rspec-users mailing list >> rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users From dhf0820 at gmail.com Thu Aug 12 18:09:08 2010 From: dhf0820 at gmail.com (Don French) Date: Thu, 12 Aug 2010 15:09:08 -0700 (PDT) Subject: [rspec-users] Autotest does not start In-Reply-To: <4092E882-6E69-4737-9725-D75D4C809BA8@gmail.com> References: <7D83AF96-AFF7-437A-9CF2-69437D51A663@patchspace.co.uk> <5fa23942-0d23-48a2-8649-cf85a97a40ab@k1g2000prl.googlegroups.com> <47718594-06f2-45d8-bf1e-c403e49cfbe0@x20g2000pro.googlegroups.com> <6D126106-0074-4676-A40F-D15C8DAE2FA1@patchspace.co.uk> <6248c7ce-d31e-4966-9200-06fdf7cf5a95@i18g2000pro.googlegroups.com> <724671BA-CD87-4BD4-BC48-88DC1545C33E@gmail.com> <4092E882-6E69-4737-9725-D75D4C809BA8@gmail.com> Message-ID: <53f7cf02-2581-42ff-a3b9-4ab511583189@k17g2000prf.googlegroups.com> yep: Autotest.add_discovery {"rspec2"} in the base project directory dhf On Aug 12, 11:32?am, David Chelimsky wrote: > On Aug 12, 2010, at 4:02 PM, Don French wrote: > > > There are lots of spec files. I can run them using rspec spec and > > everything is great. just the autotest does not work. > > Don French > > Did you create autotest/discover.rb? > > http://blog.davidchelimsky.net/2010/03/15/rspec-2-and-autotest/ > > > > > > > > > On Aug 12, 10:48 am, Don French wrote: > >> put in > >> $:.unshift(File.dirname(__FILE__) + '/../lib') > >> require 'reader' > >> and get the same thing > > >> dhf > > >> On Aug 12, 10:13 am, David Chelimsky wrote: > > >>> On Aug 12, 2010, at 3:08 PM, Don French wrote: > > >>>> The helper file does not have anything in it as of right now. It had > >>>> the the old > >>>> ?#begin > >>>> # ?require 'spec' > >>>> #rescue LoadError > >>>> # ?require 'rubygems' unless Config['NO_RUBYGEMS'] > >>>> # ?gem 'rspec' > >>>> # ?require 'spec' > >>>> #end > >>>> from rspec 1.3.0 > > >>>> Now it is empty. > > >>> I can't find it, but I could swear there was a bug report about empty spec files causing rspec to not output anything. Try putting some code in there and see what happens. > > >>>> This project was generated via newgem. > > >>>> I want to upgrade to rspec2 and ruby 1.9.2. ?Doing it in stages > >>>> currently 1.9.1. > > >>>> Don French > > >>>> On Aug 12, 8:21 am, Ashley Moran > >>>> wrote: > >>>>> On 12 Aug 2010, at 08:27, Don French wrote: > > >>>>>> under bundler bundle exec autotest ?standalone autotest both within > >>>>>> the project directory and there is a spec subdirectory with the spec > >>>>>> in them. > > >>>>> What happens when you run `rspec spec`? > > >>>>> What is in your spec_helper.rb file? > > >>>>> What is the output of `find spec`? > > >>>>> That's all I can think of asking right now... > > >>>>> --http://www.patchspace.co.uk/http://www.linkedin.com/in/ashleymoran > > >>>>> _______________________________________________ > >>>>> rspec-users mailing list > >>>>> rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users > >>>> _______________________________________________ > >>>> rspec-users mailing list > >>>> rspec-us... at rubyforge.org > >>>>http://rubyforge.org/mailman/listinfo/rspec-users > > >>> _______________________________________________ > >>> rspec-users mailing list > >>> rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users > > >> _______________________________________________ > >> rspec-users mailing list > >> rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users > > _______________________________________________ > > rspec-users mailing list > > rspec-us... at rubyforge.org > >http://rubyforge.org/mailman/listinfo/rspec-users > > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users From ashley.moran at patchspace.co.uk Fri Aug 13 11:50:23 2010 From: ashley.moran at patchspace.co.uk (Ashley Moran) Date: Fri, 13 Aug 2010 16:50:23 +0100 Subject: [rspec-users] Autotest does not start In-Reply-To: <53f7cf02-2581-42ff-a3b9-4ab511583189@k17g2000prf.googlegroups.com> References: <7D83AF96-AFF7-437A-9CF2-69437D51A663@patchspace.co.uk> <5fa23942-0d23-48a2-8649-cf85a97a40ab@k1g2000prl.googlegroups.com> <47718594-06f2-45d8-bf1e-c403e49cfbe0@x20g2000pro.googlegroups.com> <6D126106-0074-4676-A40F-D15C8DAE2FA1@patchspace.co.uk> <6248c7ce-d31e-4966-9200-06fdf7cf5a95@i18g2000pro.googlegroups.com> <724671BA-CD87-4BD4-BC48-88DC1545C33E@gmail.com> <4092E882-6E69-4737-9725-D75D4C809BA8@gmail.com> <53f7cf02-2581-42ff-a3b9-4ab511583189@k17g2000prf.googlegroups.com> Message-ID: <6435AC59-617F-45AE-8388-426AEFD74891@patchspace.co.uk> On Aug 12, 2010, at 11:09 pm, Don French wrote: > yep: Autotest.add_discovery {"rspec2"} > in the base project directory I'm at the point of asking "did you turn it off and on again?" :-/ Can you give your Ruby installation details? (versions etc, ideally the output of `rvm info` and `gem list` and/or your Gemfile) -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran From dhf0820 at gmail.com Fri Aug 13 17:16:16 2010 From: dhf0820 at gmail.com (Don French) Date: Fri, 13 Aug 2010 14:16:16 -0700 (PDT) Subject: [rspec-users] Autotest does not start In-Reply-To: <6435AC59-617F-45AE-8388-426AEFD74891@patchspace.co.uk> References: <7D83AF96-AFF7-437A-9CF2-69437D51A663@patchspace.co.uk> <5fa23942-0d23-48a2-8649-cf85a97a40ab@k1g2000prl.googlegroups.com> <47718594-06f2-45d8-bf1e-c403e49cfbe0@x20g2000pro.googlegroups.com> <6D126106-0074-4676-A40F-D15C8DAE2FA1@patchspace.co.uk> <6248c7ce-d31e-4966-9200-06fdf7cf5a95@i18g2000pro.googlegroups.com> <724671BA-CD87-4BD4-BC48-88DC1545C33E@gmail.com> <4092E882-6E69-4737-9725-D75D4C809BA8@gmail.com> <53f7cf02-2581-42ff-a3b9-4ab511583189@k17g2000prf.googlegroups.com> <6435AC59-617F-45AE-8388-426AEFD74891@patchspace.co.uk> Message-ID: <8fae30e3-de6e-4163-8045-73a4f5757ea2@t5g2000prd.googlegroups.com> Not sure what you meant by "did you turn it off and on again?" The other information is here: http://pastie.org/1091155 Don French On Aug 13, 5:50?am, Ashley Moran wrote: > On Aug 12, 2010, at 11:09 pm, Don French wrote: > > > yep: ?Autotest.add_discovery {"rspec2"} > > in the base project directory > > I'm at the point of asking "did you turn it off and on again?" :-/ > > Can you give your Ruby installation details? ?(versions etc, ideally the output of `rvm info` and `gem list` and/or your Gemfile) > > --http://www.patchspace.co.uk/http://www.linkedin.com/in/ashleymoran > > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users From dhf0820 at gmail.com Fri Aug 13 17:16:57 2010 From: dhf0820 at gmail.com (Don French) Date: Fri, 13 Aug 2010 14:16:57 -0700 (PDT) Subject: [rspec-users] Autotest does not start In-Reply-To: <6435AC59-617F-45AE-8388-426AEFD74891@patchspace.co.uk> References: <7D83AF96-AFF7-437A-9CF2-69437D51A663@patchspace.co.uk> <5fa23942-0d23-48a2-8649-cf85a97a40ab@k1g2000prl.googlegroups.com> <47718594-06f2-45d8-bf1e-c403e49cfbe0@x20g2000pro.googlegroups.com> <6D126106-0074-4676-A40F-D15C8DAE2FA1@patchspace.co.uk> <6248c7ce-d31e-4966-9200-06fdf7cf5a95@i18g2000pro.googlegroups.com> <724671BA-CD87-4BD4-BC48-88DC1545C33E@gmail.com> <4092E882-6E69-4737-9725-D75D4C809BA8@gmail.com> <53f7cf02-2581-42ff-a3b9-4ab511583189@k17g2000prf.googlegroups.com> <6435AC59-617F-45AE-8388-426AEFD74891@patchspace.co.uk> Message-ID: I converted from rspec 1.3 to rspec 2 On Aug 13, 5:50?am, Ashley Moran wrote: > On Aug 12, 2010, at 11:09 pm, Don French wrote: > > > yep: ?Autotest.add_discovery {"rspec2"} > > in the base project directory > > I'm at the point of asking "did you turn it off and on again?" :-/ > > Can you give your Ruby installation details? ?(versions etc, ideally the output of `rvm info` and `gem list` and/or your Gemfile) > > --http://www.patchspace.co.uk/http://www.linkedin.com/in/ashleymoran > > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users From knarayanan88 at gmail.com Fri Aug 13 23:20:29 2010 From: knarayanan88 at gmail.com (Narayanan) Date: Fri, 13 Aug 2010 20:20:29 -0700 (PDT) Subject: [rspec-users] [rspec] Installation Problem Message-ID: <24d9e2f4-8e27-4d89-b5e5-5a67ac17bf4d@g6g2000pro.googlegroups.com> Hi friends, I have installed and used RSpec many times before. After a long time, I am back to RSpec and I tried installing this gem. But am not able to install it. Following are the details: $ gem install rspec ************************************************** Thank you for installing rspec-1.3.0 Please be sure to read History.rdoc and Upgrade.rdoc for useful information about this release. ************************************************** Successfully installed rspec-1.3.0 1 gem installed Installing ri documentation for rspec-1.3.0... Installing RDoc documentation for rspec-1.3.0... Could not find main page README.rdoc Could not find main page README.rdoc Could not find main page README.rdoc Could not find main page README.rdoc $ spec -bash: spec: command not found But running: $gem list --local shows rspec (1.3.0) $ ls /var/lib/gems/1.8/gems/rspec-1.3.0/bin autospec spec Also there all files related to rspec installation in /var/lib/gems/ 1.8/gems/rspec-1.3.0/ including the README.rdoc. Please help me why I am not able to use spec command after installing it with the above error. I would be greatly thankful if you could point to me what I am missing... Have a great day, Thanks and Regards, Narayanan India. From knarayanan88 at gmail.com Sat Aug 14 01:57:05 2010 From: knarayanan88 at gmail.com (Narayanan) Date: Fri, 13 Aug 2010 22:57:05 -0700 (PDT) Subject: [rspec-users] [rspec] Installation Problem In-Reply-To: <24d9e2f4-8e27-4d89-b5e5-5a67ac17bf4d@g6g2000pro.googlegroups.com> References: <24d9e2f4-8e27-4d89-b5e5-5a67ac17bf4d@g6g2000pro.googlegroups.com> Message-ID: <5d6e7a4d-f72b-4f4c-af3c-17c7c49ca581@g6g2000pro.googlegroups.com> Hi, Found out the problem. Was a rather a simple one, The rubygems installation hadn't updated the environment PATH variable with the path of all gem executables. So, $gem environment Notice the GEM PATHS I found my gem executables in /var/lib/gems/1.8/bin Append this path to PATH env variable in ~/.bashrc file using an export command to solve the problem. Thanks, Narayanan From lists at ruby-forum.com Sat Aug 14 06:34:12 2010 From: lists at ruby-forum.com (Mike Howson) Date: Sat, 14 Aug 2010 12:34:12 +0200 Subject: [rspec-users] Module & Mixin testing strategy Message-ID: <66a17881cd8be1321947088954978d4e@ruby-forum.com> Hi, Just wondered what people thoughts are to testing module's to be included in mixin's? Seems to me there are two main approaches:- 1. Test the behavior in a mixin object that includes the module because its the behavior of the object thats important not the code structure. 2. Test the module in isolation as it potentially code be included anywhere. If the best approach is 2 - to test the module in isolation and the module uses instance variables or methods from the object its being mixed with then we would need to create a test object in the rspec test that included the module and defined the required instance variables and methods. Does this lead to 1 being the best approach as we are not then forced to mock up a mixin just to test the module? The question came about because I recently had to get an untested rails module under test that was included in a number of controllers and depended on 'request' and 'response'. I was then faced with either testing one of the controllers that included that module but also added further complexity or defining a new thin controller used solely for testing the module within the spec file. Interested to know your thoughts! Victor -- Posted via http://www.ruby-forum.com/. From ashley.moran at patchspace.co.uk Sat Aug 14 10:26:25 2010 From: ashley.moran at patchspace.co.uk (Ashley Moran) Date: Sat, 14 Aug 2010 15:26:25 +0100 Subject: [rspec-users] Module & Mixin testing strategy In-Reply-To: <66a17881cd8be1321947088954978d4e@ruby-forum.com> References: <66a17881cd8be1321947088954978d4e@ruby-forum.com> Message-ID: On 14 Aug 2010, at 11:34, Mike Howson wrote: > Just wondered what people thoughts are to testing module's to be > included in mixin's? Seems to me there are two main approaches:- Hi Mike I've been doing a lot of this sort of coding lately, as I've been extracting duplicated code into a mini-framework based on modules. > 1. Test the behavior in a mixin object that includes the module because > its the behavior of the object thats important not the code structure. > > 2. Test the module in isolation as it potentially code be included > anywhere. I'm not sure I know how option 2 is even possible, unless your module is all module methods, as you can't call instance methods on a module directly. However, it's easy to do this in RSpec with some Ruby meta-magic: module MyModule def foo "bar" end end describe MyModule do let(:class_with_my_module) { Class.new do include MyModule end } subject { class_with_my_module.new } its(:foo) { should eq bar } end > If the best approach is 2 - to test the module in isolation and the > module uses instance variables or methods from the object its being > mixed with then we would need to create a test object in the rspec test > that included the module and defined the required instance variables and > methods. Does this lead to 1 being the best approach as we are not then > forced to mock up a mixin just to test the module? I'm not 100% sure but I *think* the snippet above is an implementation of what you describe here. Please correct me if I misunderstood. > The question came about because I recently had to get an untested rails > module under test that was included in a number of controllers and > depended on 'request' and 'response'. I was then faced with either > testing one of the controllers that included that module but also added > further complexity or defining a new thin controller used solely for > testing the module within the spec file. In this case, you may be able to get some mileage with the above code, but using `Class.new(ActionController::Base)`. You can test individual objects that include your module with shared examples, for example: module Fooable def foo "bar" end end class Baz include Fooable # Oops - this is overriding Fooable#foo def foo "quux" end end shared_examples_for "a Fooable object" do # Optional before(:each) do unless respond_to?(:fooable) raise "You must provide instance method fooable" end end it "should have a foo of 'bar'" do fooable.foo.should eq "bar" end end describe Baz do subject { Baz.new } it_should_behave_like "a Fooable object" do let(:fooable) { subject } end end My recommendation at the moment is to make the shared examples work fully-integrated (ie, no mocks). I've run into issue where shared examples rely on mocks, which I haven't solved yet (at least not in my code - it's my next TODO). Currently I'm doing both the above. The isolated module spec proves the module enchants objects with the correct behaviour, the shared examples double-check that you haven't broken that behaviour in concrete classes. See also the recent thread "Evaluating shared example customisation block before shared block" from 30th July onwards (it goes on to talk about passing parameters to shared example groups, which is possible in RSpec-2 master). HTH Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran From ashley.moran at patchspace.co.uk Sat Aug 14 10:40:31 2010 From: ashley.moran at patchspace.co.uk (Ashley Moran) Date: Sat, 14 Aug 2010 15:40:31 +0100 Subject: [rspec-users] Autotest does not start In-Reply-To: <8fae30e3-de6e-4163-8045-73a4f5757ea2@t5g2000prd.googlegroups.com> References: <7D83AF96-AFF7-437A-9CF2-69437D51A663@patchspace.co.uk> <5fa23942-0d23-48a2-8649-cf85a97a40ab@k1g2000prl.googlegroups.com> <47718594-06f2-45d8-bf1e-c403e49cfbe0@x20g2000pro.googlegroups.com> <6D126106-0074-4676-A40F-D15C8DAE2FA1@patchspace.co.uk> <6248c7ce-d31e-4966-9200-06fdf7cf5a95@i18g2000pro.googlegroups.com> <724671BA-CD87-4BD4-BC48-88DC1545C33E@gmail.com> <4092E882-6E69-4737-9725-D75D4C809BA8@gmail.com> <53f7cf02-2581-42ff-a3b9-4ab511583189@k17g2000prf.googlegroups.com> <6435AC59-617F-45AE-8388-426AEFD74891@patchspace.co.uk> <8fae30e3-de6e-4163-8045-73a4f5757ea2@t5g2000prd.googlegroups.com> Message-ID: On 13 Aug 2010, at 22:16, Don French wrote: > Not sure what you meant by "did you turn it off and on again?" Ah, I just meant I was running out of ideas[1]. > The other information is here: > http://pastie.org/1091155 All I can suggest is maybe updating RVM and trying in Ruby 1.9.2 with a fresh gemset and bundle install? Other than that I'm out of ideas... Ash [1] http://www.youtube.com/watch?v=QpmLrz_lSuE -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran From dchelimsky at gmail.com Sat Aug 14 10:50:16 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 14 Aug 2010 09:50:16 -0500 Subject: [rspec-users] Module & Mixin testing strategy In-Reply-To: <66a17881cd8be1321947088954978d4e@ruby-forum.com> References: <66a17881cd8be1321947088954978d4e@ruby-forum.com> Message-ID: On Aug 14, 2010, at 5:34 AM, Mike Howson wrote: > Hi, > > Just wondered what people thoughts are to testing module's to be > included in mixin's? Seems to me there are two main approaches:- > > 1. Test the behavior in a mixin object that includes the module because > its the behavior of the object thats important not the code structure. > > 2. Test the module in isolation as it potentially code be included > anywhere. 3. All of the above, and then some ... I need to blog this, which I'll do later, but here is the short version: Consider this structure: module M; end class C include M end We specify responsibilities of objects from the perspective of their consumers. If module M is included in class C, consumers of class C have no reason to know that module M is involved. They just care about the behaviour. Same is true of classes A, B, and C, if they each include module M. Keeping in mind that each host class/object (classes and modules that include or extend M) can override any of the behaviour of M, each host should therefore be specified independently. Additionally, if module M enforces some rule, like host objects (i.e. classes and modules that include or extend M) must implement method F, then that responsibility belongs to M, and should be specified in the context of M, not any of its host classes/objects. So we're interested in specifying two things: a. the behaviour of each class/object that mixes in M in response to events triggered by their consumers b. the behaviour of M in response to being mixed in For specifying the behaviour of M in response to being mixed in, I typically mix M into anonymous classes and objects and specify what happens. Brief example: describe M do it "requires host object to provide a foo method" do host = Object.new expect do host.extend(M) end.to raise_error(/Objects which extend M must provide a foo method/) end end For specifying the behaviour of host classes/objects, I've used a combination of shared example groups and custom macros in the past, but I don't think the macros will be necessary any longer. Thanks to some lively discussion [1-5], and code from Wincent Colaiuta, Ashley Moran and Myron Marsten, shared example groups just got _awesome_! They can now be parameterized and/or customized in three different ways. The biggest change came from having it_should_behave_like (and its new alias, it_behaves_like), generate a nested example group instead of mixing a module directly into the host group. This means that these two are equivalent: ### shared_examples_for M it "does something" do # .... end end describe C do it_behaves_like M end ### ### describe C do context "behaves like M" do it "does something" do # .... end end end ### In rspec-1, shared groups are modules that get mixed into the host group, which means material defined in the shared group can impact the host group in surprising ways. With this new structure in rspec-2, the nested group is a completely separate group, and combination of sharing behaviour (through inheritance) and isolating behaviour (through encapsulation) provides power we never had before. Here are the techniques for customizing shared groups: # Parameterization describe Host do it_should_behave_like M, Host.new end Here, the result of Host.new is passed to the shared group as a block parameter, making that value available at the group level (each example group is a class), and the instance level (each example runs in an _instance_ of that class). So ... shared_examples_for M do |host| it "can access #{host} in the docstring" do host.do_something # it can access the host _in_ the example end end # Methods defined in host group describe Host do let(:foo) { Host.new } it_should_behave_like M end In this case, the foo method defined by let is inherited by the generated nested example group. Inherited methods like this are only available in the scope in which they are defined, so foo would be available at the instance level (i.e. in examples). If foo was defined as a class method, then it would be available at the class level in the nested group as well. # Methods defined in an extension block describe Host do it_should_behave_like M do let(:foo) { Host.new } end end In this case, the block passed to it_should_behave_like is eval'd after the shared group is eval'd. The combo of the extension block and inherited methods allows us to define groups that programmatically enforce rules for the host groups. For example: shared_examples_for M do unless respond_to?(:foo) raise "Groups that include shared examples for M must provide a foo method" end end This means that library authors can now ship shared groups that will instruct end users how to use them. Awesome!!!!!!! I'll amend and refine this in a blog post sometime soon, but hopefully this is a helpful overview. Cheers, David [1] http://github.com/rspec/rspec-core/issues/issue/71 [2] http://github.com/rspec/rspec-core/issues/issue/74 [3] http://groups.google.com/group/rspec/browse_thread/thread/f5620df1c42874bf# [4] http://groups.google.com/group/rspec/browse_thread/thread/16d553ee2e51ccbd# [5] http://groups.google.com/group/rspec/browse_thread/thread/a23d5fb84a31f11e# > If the best approach is 2 - to test the module in isolation and the > module uses instance variables or methods from the object its being > mixed with then we would need to create a test object in the rspec test > that included the module and defined the required instance variables and > methods. Does this lead to 1 being the best approach as we are not then > forced to mock up a mixin just to test the module? > > The question came about because I recently had to get an untested rails > module under test that was included in a number of controllers and > depended on 'request' and 'response'. I was then faced with either > testing one of the controllers that included that module but also added > further complexity or defining a new thin controller used solely for > testing the module within the spec file. > > Interested to know your thoughts! > > Victor > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users From dchelimsky at gmail.com Sat Aug 14 10:53:32 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 14 Aug 2010 09:53:32 -0500 Subject: [rspec-users] Module & Mixin testing strategy In-Reply-To: References: <66a17881cd8be1321947088954978d4e@ruby-forum.com> Message-ID: On Aug 14, 2010, at 9:26 AM, Ashley Moran wrote: > > On 14 Aug 2010, at 11:34, Mike Howson wrote: > >> Just wondered what people thoughts are to testing module's to be >> included in mixin's? Seems to me there are two main approaches:- > > Hi Mike > > I've been doing a lot of this sort of coding lately, as I've been extracting duplicated code into a mini-framework based on modules. > > >> 1. Test the behavior in a mixin object that includes the module because >> its the behavior of the object thats important not the code structure. >> >> 2. Test the module in isolation as it potentially code be included >> anywhere. > > I'm not sure I know how option 2 is even possible, unless your module is all module methods, as you can't call instance methods on a module directly. > > However, it's easy to do this in RSpec with some Ruby meta-magic: > > module MyModule > def foo > "bar" > end > end > > describe MyModule do > let(:class_with_my_module) { > Class.new do > include MyModule > end > } > > subject { class_with_my_module.new } > > its(:foo) { should eq bar } > end Or: describe M do it "does something" do host = Object.new.extend(M) host.some_method_defined_in_m.should do_something end end I think either approach satisfies "test the module in isolation", even though it's not in isolation from the behaviour of Object. > If the best approach is 2 - to test the module in isolation and the >> module uses instance variables or methods from the object its being >> mixed with then we would need to create a test object in the rspec test >> that included the module and defined the required instance variables and >> methods. Does this lead to 1 being the best approach as we are not then >> forced to mock up a mixin just to test the module? > > I'm not 100% sure but I *think* the snippet above is an implementation of what you describe here. Please correct me if I misunderstood. > > >> The question came about because I recently had to get an untested rails >> module under test that was included in a number of controllers and >> depended on 'request' and 'response'. I was then faced with either >> testing one of the controllers that included that module but also added >> further complexity or defining a new thin controller used solely for >> testing the module within the spec file. > > In this case, you may be able to get some mileage with the above code, but using `Class.new(ActionController::Base)`. > > You can test individual objects that include your module with shared examples, for example: > > module Fooable > def foo > "bar" > end > end > > class Baz > include Fooable > > # Oops - this is overriding Fooable#foo > def foo > "quux" > end > end > > shared_examples_for "a Fooable object" do > # Optional > before(:each) do > unless respond_to?(:fooable) > raise "You must provide instance method fooable" > end > end > > it "should have a foo of 'bar'" do > fooable.foo.should eq "bar" > end > end > > describe Baz do > subject { Baz.new } > it_should_behave_like "a Fooable object" do > let(:fooable) { subject } > end > end > > My recommendation at the moment is to make the shared examples work fully-integrated (ie, no mocks). I've run into issue where shared examples rely on mocks, which I haven't solved yet (at least not in my code - it's my next TODO). > > Currently I'm doing both the above. The isolated module spec proves the module enchants objects with the correct behaviour, the shared examples double-check that you haven't broken that behaviour in concrete classes. > > See also the recent thread "Evaluating shared example customisation block before shared block" from 30th July onwards (it goes on to talk about passing parameters to shared example groups, which is possible in RSpec-2 master). > > HTH > > Ash > > -- > http://www.patchspace.co.uk/ > http://www.linkedin.com/in/ashleymoran > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users From lists at ruby-forum.com Sat Aug 14 11:44:16 2010 From: lists at ruby-forum.com (Bogdan Gusiev) Date: Sat, 14 Aug 2010 17:44:16 +0200 Subject: [rspec-users] testing named_scope In-Reply-To: References: Message-ID: Nin wrote: > Hi! I'm new to rspec and was wondering how named_scopes are usually > tested? Is it enough to test that it's defined? or do you need to test > the behavior as well? I've been reading around and this seems to be > the tester's choice, i just want to get people's opinion on this :D Here is my approach: http://gusiev.com/2010/07/bdd-rspec-matcher-to-test-named_scope-scoped-rails-3/ It is a little advanced. Hopefully you will get the idea. -- Posted via http://www.ruby-forum.com/. From ashley.moran at patchspace.co.uk Sat Aug 14 12:09:50 2010 From: ashley.moran at patchspace.co.uk (Ashley Moran) Date: Sat, 14 Aug 2010 17:09:50 +0100 Subject: [rspec-users] Module & Mixin testing strategy In-Reply-To: References: <66a17881cd8be1321947088954978d4e@ruby-forum.com> Message-ID: <1A67629C-C3A0-4946-A5AA-773C3BE80B89@patchspace.co.uk> On 14 Aug 2010, at 15:50, David Chelimsky wrote: > I need to blog this, which I'll do later, but here is the short version: You could pretty much copy and paste that "short version" into a chapter of the RSpec Book, never mind a blog post ;) -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran From kmandrup.github at gmail.com Sat Aug 14 12:42:09 2010 From: kmandrup.github at gmail.com (Kristian Mandrup) Date: Sat, 14 Aug 2010 09:42:09 -0700 (PDT) Subject: [rspec-users] generator-spec release 0.4.8 In-Reply-To: <76af1dfc-1b0b-445b-b4af-7a27f662fc91@w30g2000yqw.googlegroups.com> References: <76af1dfc-1b0b-445b-b4af-7a27f662fc91@w30g2000yqw.googlegroups.com> Message-ID: Just released 0.5.0, a pretty stable release with a large rspec test suite to show it off and ensure it works as it should :) On Aug 11, 6:02?pm, Kristian Mandrup wrote: > Now with an almost complete test suite to ensure it all works as it > should and to demonstrate how to use it. > The DSL is better than ever! > > describe 'model_generator' do > ? # include Rails model helpers for ActiveRecord > ? # available: > > ? # Other ORM options - :mongo_mapper, :mongoid and :data_mapper > ? # note: use_orm auto-includes the :model helper module > ? use_orm :active_record > > ? # load helper modules and make available inside spec blocks > ? # here the module in rails_helpers/rails_migration is included > ? helpers :migration > > ? before :each do > ? ? # define generator to test > ? ? setup_generator 'model_generator' do > ? ? ? tests Canable::Generators::ModelGenerator > ? ? end > ? ? # ensure clean state before each run > ? ? remove_model :account > ? end > > ? after :each do > ? ? # ensure clean state after each run > ? ? remove_model :account > ? end > > ? it "should not work without an existing Account model file" > do > ? ? with_generator do |g| > ? ? ? g.run_generator :account.args > ? ? ? g.should_not generate_file :account, :model > ? ? end > ? end > > ? it "should decorate an existing Account model file with 'include > Canable:Ables'" do > ? ? with_generator do |g| > ? ? ? create_model :account > ? ? ? g.run_generator 'account'.args > ? ? ? g.should generate_model :account do |content| > ? ? ? ? content.should have_class :account do |klass| > ? ? ? ? ? klass.should include_module 'Canable::Ables' > ? ? ? ? end > ? ? ? end > ? ? end > ? end > end > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users From dhf0820 at gmail.com Sat Aug 14 13:49:48 2010 From: dhf0820 at gmail.com (Don French) Date: Sat, 14 Aug 2010 10:49:48 -0700 (PDT) Subject: [rspec-users] Autotest does not start In-Reply-To: References: <5fa23942-0d23-48a2-8649-cf85a97a40ab@k1g2000prl.googlegroups.com> <47718594-06f2-45d8-bf1e-c403e49cfbe0@x20g2000pro.googlegroups.com> <6D126106-0074-4676-A40F-D15C8DAE2FA1@patchspace.co.uk> <6248c7ce-d31e-4966-9200-06fdf7cf5a95@i18g2000pro.googlegroups.com> <724671BA-CD87-4BD4-BC48-88DC1545C33E@gmail.com> <4092E882-6E69-4737-9725-D75D4C809BA8@gmail.com> <53f7cf02-2581-42ff-a3b9-4ab511583189@k17g2000prf.googlegroups.com> <6435AC59-617F-45AE-8388-426AEFD74891@patchspace.co.uk> <8fae30e3-de6e-4163-8045-73a4f5757ea2@t5g2000prd.googlegroups.com> Message-ID: <39ef5421-0865-4b40-9896-fe0eb1c4f7ef@l32g2000prn.googlegroups.com> Thought that was what you meant, but did not want to leave anything untried. I have updated to 1.9.2-rc2. same problem. I am going to have to do an update to snow leopard soon, may try it and put new code on not just restore. Don French On Aug 14, 4:40?am, Ashley Moran wrote: > On 13 Aug 2010, at 22:16, Don French wrote: > > > Not sure what you meant by ?"did you turn it off and on again?" > > Ah, I just meant I was running out of ideas[1]. > > > The other information is here: > >http://pastie.org/1091155 > > All I can suggest is maybe updating RVM and trying in Ruby 1.9.2 with a fresh gemset and bundle install? > > Other than that I'm out of ideas... > > Ash > > [1]http://www.youtube.com/watch?v=QpmLrz_lSuE > > --http://www.patchspace.co.uk/http://www.linkedin.com/in/ashleymoran > > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users From ashley.moran at patchspace.co.uk Sat Aug 14 15:36:53 2010 From: ashley.moran at patchspace.co.uk (Ashley Moran) Date: Sat, 14 Aug 2010 20:36:53 +0100 Subject: [rspec-users] Autotest does not start In-Reply-To: <39ef5421-0865-4b40-9896-fe0eb1c4f7ef@l32g2000prn.googlegroups.com> References: <5fa23942-0d23-48a2-8649-cf85a97a40ab@k1g2000prl.googlegroups.com> <47718594-06f2-45d8-bf1e-c403e49cfbe0@x20g2000pro.googlegroups.com> <6D126106-0074-4676-A40F-D15C8DAE2FA1@patchspace.co.uk> <6248c7ce-d31e-4966-9200-06fdf7cf5a95@i18g2000pro.googlegroups.com> <724671BA-CD87-4BD4-BC48-88DC1545C33E@gmail.com> <4092E882-6E69-4737-9725-D75D4C809BA8@gmail.com> <53f7cf02-2581-42ff-a3b9-4ab511583189@k17g2000prf.googlegroups.com> <6435AC59-617F-45AE-8388-426AEFD74891@patchspace.co.uk> <8fae30e3-de6e-4163-8045-73a4f5757ea2@t5g2000prd.googlegroups.com> <39ef5421-0865-4b40-9896-fe0eb1c4f7ef@l32g2000prn.googlegroups.com> Message-ID: On 14 Aug 2010, at 18:49, Don French wrote: > Thought that was what you meant, but did not want to leave anything > untried. I have updated to 1.9.2-rc2. same problem. I am going to > have to do an update to snow leopard soon, may try it and put new code > on not just restore. I wish I could help more, but I'm flat out of ideas. I don't think I'd be able to do any more without being at your machine. -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran From dane.harrigan at gmail.com Tue Aug 10 10:21:57 2010 From: dane.harrigan at gmail.com (Dane Harrigan) Date: Tue, 10 Aug 2010 07:21:57 -0700 (PDT) Subject: [rspec-users] Including modules for view test in RSpec 2.0.0.beta.19 Message-ID: <32ce25e8-bb46-407b-b8a9-d30a39f02e75@j8g2000yqd.googlegroups.com> Hey guys, I used RSpec 1.3 quite a bit and wanted to move to 2.0. I'm having some trouble, but I think I'm just missing something. On this pastie you'll see my spec/support/view_helpers.rb, spec/ spec_helper.rb file and header.haml spec file., http://pastie.org/1081962 On line 11 of the spec_helper.rb I include my ViewHelpers module in the views, but my "should_have_a_link" doesn't exist in the header.haml spec file until I include it there on line 4 of the file. I'm sure I'm missing something, but I see what it is. Thanks in advance everyone, -Dane From bpauly at gmail.com Tue Aug 10 12:17:07 2010 From: bpauly at gmail.com (Brad Pauly) Date: Tue, 10 Aug 2010 09:17:07 -0700 (PDT) Subject: [rspec-users] rspec command for rspec-2.0.0.beta.19 Message-ID: <1b3ad1b2-488f-4b7d-a9ff-1ac60e1bba20@p12g2000prn.googlegroups.com> I've just uninstalled all versions of rspec and installed rspec-2.0.0.beta.19 and rspec-rails-2.0.0.beta.19 for a rails project and I can't find the rspec command. Based on what bundler is telling me, I think it should be in: /usr/local/lib/ruby/gems/1.8/gems/bin/ but it isn't. $ bundle show rspec /usr/local/lib/ruby/gems/1.8/gems/rspec-2.0.0.beta.19 Everything seems to have installed properly with "bundle install" $ bundle show | grep rspec * rspec (2.0.0.beta.19) * rspec-core (2.0.0.beta.19) * rspec-expectations (2.0.0.beta.19) * rspec-mocks (2.0.0.beta.19) * rspec-rails (2.0.0.beta.19) Anyone have ideas on where I should be looking or a direction to go? Cheers, Brad From john.firebaugh at gmail.com Tue Aug 10 16:52:16 2010 From: john.firebaugh at gmail.com (John Firebaugh) Date: Tue, 10 Aug 2010 13:52:16 -0700 (PDT) Subject: [rspec-users] issue with rescue_action_in_public! and testing 404 responses In-Reply-To: <8AF62E18-794E-40B2-BB82-95B2A21FDB9B@gmail.com> References: <29382281.post@talk.nabble.com> <8AF62E18-794E-40B2-BB82-95B2A21FDB9B@gmail.com> Message-ID: On Aug 9, 7:21?pm, David Chelimsky wrote: > It's up to you to handle the error in the controller. Something like this in ApplicationController: > > ? rescue_from ActiveRecord::RecordNotFound do > ? ? render '/404.html', :layout => false, :status => :not_found > ? end Actually, I believe this is a bug in Rails 3. ActiveRecord::RecordNotFound should be handled automatically by the ActionDispatch::ShowExceptions middleware, and then rescue_action_in_public! in your controller test should continue to work as it did in Rails 2, allowing you to verify the result is a 404. I posted to rails-core about this issue: http://groups.google.com/group/rubyonrails-core/browse_thread/thread/e7379309d2308f28 From john.firebaugh at gmail.com Tue Aug 10 16:47:50 2010 From: john.firebaugh at gmail.com (John Firebaugh) Date: Tue, 10 Aug 2010 13:47:50 -0700 (PDT) Subject: [rspec-users] Specifying which spec types helper modules get included into in the RSpec.configure block In-Reply-To: <6e2e4c8f-f7cc-450e-a150-a20da2bb81f1@l14g2000yql.googlegroups.com> References: <6e2e4c8f-f7cc-450e-a150-a20da2bb81f1@l14g2000yql.googlegroups.com> Message-ID: On Jul 30, 9:14?am, S Bennett wrote: > Am I doing something wrong or has the syntax for specifying which spec > types the modules get included into changed? I have the same problem. I filed an issue: http://github.com/rspec/rspec-rails/issues/issue/159 From samullen at gmail.com Wed Aug 11 12:56:34 2010 From: samullen at gmail.com (samullen) Date: Wed, 11 Aug 2010 09:56:34 -0700 (PDT) Subject: [rspec-users] Calling script/spec from directories other than RAILS_ROOT Message-ID: <0ca37a1d-c372-4ce9-a6f9-16cc1d546751@l6g2000yqb.googlegroups.com> I've written a simple shell function which, depending on where it is called, will ascend the directory tree until it finds ./script/spec or, failing that, the spec first found in $PATH. What I'm running into is that although my tests pass when I call script/spec from RAILS_ROOT, they do not pass when it's called from any other location. This happens regardless of whether I use my function or call spec directly. Examples: from RAILS_ROOT - script/spec spec/controllers/actors_controller_spec.rb # Passes from /home/fooman/rails_project/spec/controllers - /home/fooman/rails_project/script/spec actors_controller_spec.rb # FAILS because it can't find 'request' What do I need to do to run spec for a rails project in a directory other than RAILS_ROOT? Thank you, Samuel Mullen From craig.castelaz at gmail.com Sat Aug 14 00:33:26 2010 From: craig.castelaz at gmail.com (Craig Castelaz) Date: Sat, 14 Aug 2010 00:33:26 -0400 Subject: [rspec-users] 2.0.0.beta.19 installation problem Message-ID: I purchased the beta version of the PragBook yesterday, but didn't get a chance to begin reading until tonight. I'm currently stuck on installing rspec. ~$ sudo gem install rspec --version 2.0.0.beta.19 ************************************************** Thank you for installing rspec-core-2.0.0.beta.19 Please be sure to look at Upgrade.markdown to see what might have changed since the last release. ************************************************** ************************************************** Thank you for installing rspec-expectations-2.0.0.beta.19 ************************************************** ************************************************** Thank you for installing rspec-mocks-2.0.0.beta.19 ************************************************** ERROR: Error installing rspec: rspec requires rspec-core (= 2.0.0.beta.19, runtime) I'm a bit mystified because the process begins by installing rspec-core-2.0.0.beta.19, but ends by telling me rspec-core (2.0.0.beta.19) is required. I'm running Ruby 1.8.7 on OS 10.6.4 if that's of any help. Thanks, Craig From dchelimsky at gmail.com Mon Aug 16 00:39:19 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 15 Aug 2010 23:39:19 -0500 Subject: [rspec-users] rspec command for rspec-2.0.0.beta.19 In-Reply-To: <1b3ad1b2-488f-4b7d-a9ff-1ac60e1bba20@p12g2000prn.googlegroups.com> References: <1b3ad1b2-488f-4b7d-a9ff-1ac60e1bba20@p12g2000prn.googlegroups.com> Message-ID: On Tue, Aug 10, 2010 at 11:17 AM, Brad Pauly wrote: > I've just uninstalled all versions of rspec and installed > rspec-2.0.0.beta.19 and rspec-rails-2.0.0.beta.19 for a rails project > and I can't find the rspec command. Based on what bundler is telling > me, I think it should be in: /usr/local/lib/ruby/gems/1.8/gems/bin/ > but it isn't. > > $ bundle show rspec > /usr/local/lib/ruby/gems/1.8/gems/rspec-2.0.0.beta.19 > > Everything seems to have installed properly with "bundle install" > > $ bundle show | grep rspec > ?* rspec (2.0.0.beta.19) > ?* rspec-core (2.0.0.beta.19) > ?* rspec-expectations (2.0.0.beta.19) > ?* rspec-mocks (2.0.0.beta.19) > ?* rspec-rails (2.0.0.beta.19) > > Anyone have ideas on where I should be looking or a direction to go? If bundler installs it, then you have to run it under 'bundle exec': bundle exec rspec I've got an alias set up so I can say: be rspec spec There's something metaphysically pleasing about that. HTH, David > > Cheers, > Brad > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From dchelimsky at gmail.com Mon Aug 16 00:45:16 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 15 Aug 2010 23:45:16 -0500 Subject: [rspec-users] Calling script/spec from directories other than RAILS_ROOT In-Reply-To: <0ca37a1d-c372-4ce9-a6f9-16cc1d546751@l6g2000yqb.googlegroups.com> References: <0ca37a1d-c372-4ce9-a6f9-16cc1d546751@l6g2000yqb.googlegroups.com> Message-ID: On Wed, Aug 11, 2010 at 11:56 AM, samullen wrote: > I've written a simple shell function which, depending on where it is > called, will ascend the directory tree until it finds ./script/spec > or, failing that, the spec first found in $PATH. What I'm running into > is that although my tests pass when I call script/spec from > RAILS_ROOT, they do not pass when it's called from any other location. > This happens regardless of whether I use my function or call spec > directly. > > Examples: > from RAILS_ROOT - > script/spec spec/controllers/actors_controller_spec.rb # Passes > > from /home/fooman/rails_project/spec/controllers - > /home/fooman/rails_project/script/spec actors_controller_spec.rb # > FAILS because it can't find 'request' > > What do I need to do to run spec for a rails project in a directory > other than RAILS_ROOT? 1. add :type => controller, :type => view, etc so RSpec knows what kind of example group to load 1.a. if you're using rspec-2, you'll have to include the correct module instead 2. use absolute paths to require spec_helper Personally, I'd just keep running the specs from the project root. HTH, David > > Thank you, > Samuel Mullen > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From dchelimsky at gmail.com Mon Aug 16 00:48:52 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 15 Aug 2010 23:48:52 -0500 Subject: [rspec-users] Including modules for view test in RSpec 2.0.0.beta.19 In-Reply-To: <32ce25e8-bb46-407b-b8a9-d30a39f02e75@j8g2000yqd.googlegroups.com> References: <32ce25e8-bb46-407b-b8a9-d30a39f02e75@j8g2000yqd.googlegroups.com> Message-ID: On Tue, Aug 10, 2010 at 9:21 AM, Dane Harrigan wrote: > Hey guys, > > I used RSpec 1.3 quite a bit and wanted to move to 2.0. I'm having > some trouble, but I think I'm just missing something. > > On this pastie you'll see my spec/support/view_helpers.rb, spec/ > spec_helper.rb file and header.haml spec file., http://pastie.org/1081962 > > On line 11 of the spec_helper.rb I include my ViewHelpers module in > the views, but my "should_have_a_link" doesn't exist in the > header.haml spec file until I include it there on line 4 of the file. > I'm sure I'm missing something, but I see what it is. > > Thanks in advance everyone, Known issue: http://github.com/rspec/rspec-rails/issues/closed#issue/159 Fixed just a day or two ago and will be part of the next release (beta 20) which will be sometime in the next week or so. Would have been sooner, but I just got the book back from indexing (w0000t) and I have some work to do before it goes off to the copyeditor (double w00000t). In the mean time, you can point your Gemfile at github and get the latest and greatest (keep in mind this has its own costs because you're dealing with a moving target) - see "Living on edge" on http://github.com/rspec/rspec-rails. HTH, David > -Dane > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From dchelimsky at gmail.com Mon Aug 16 00:50:20 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 15 Aug 2010 23:50:20 -0500 Subject: [rspec-users] Specifying which spec types helper modules get included into in the RSpec.configure block In-Reply-To: References: <6e2e4c8f-f7cc-450e-a150-a20da2bb81f1@l14g2000yql.googlegroups.com> Message-ID: On Tue, Aug 10, 2010 at 3:47 PM, John Firebaugh wrote: > On Jul 30, 9:14?am, S Bennett wrote: >> Am I doing something wrong or has the syntax for specifying which spec >> types the modules get included into changed? > > I have the same problem. I filed an issue: > > http://github.com/rspec/rspec-rails/issues/issue/159 It's been fixed, and the fix will be part of the next release (next week or so). From patmaddox at me.com Mon Aug 16 00:53:12 2010 From: patmaddox at me.com (Pat Maddox) Date: Sun, 15 Aug 2010 21:53:12 -0700 Subject: [rspec-users] rspec command for rspec-2.0.0.beta.19 In-Reply-To: <1b3ad1b2-488f-4b7d-a9ff-1ac60e1bba20@p12g2000prn.googlegroups.com> References: <1b3ad1b2-488f-4b7d-a9ff-1ac60e1bba20@p12g2000prn.googlegroups.com> Message-ID: <82708CF2-D9AB-44CA-979F-D65E99137183@me.com> What does "gem list rspec" show? And "echo $PATH" ? On Aug 10, 2010, at 9:17 AM, Brad Pauly wrote: > I've just uninstalled all versions of rspec and installed > rspec-2.0.0.beta.19 and rspec-rails-2.0.0.beta.19 for a rails project > and I can't find the rspec command. Based on what bundler is telling > me, I think it should be in: /usr/local/lib/ruby/gems/1.8/gems/bin/ > but it isn't. > > $ bundle show rspec > /usr/local/lib/ruby/gems/1.8/gems/rspec-2.0.0.beta.19 > > Everything seems to have installed properly with "bundle install" > > $ bundle show | grep rspec > * rspec (2.0.0.beta.19) > * rspec-core (2.0.0.beta.19) > * rspec-expectations (2.0.0.beta.19) > * rspec-mocks (2.0.0.beta.19) > * rspec-rails (2.0.0.beta.19) > > Anyone have ideas on where I should be looking or a direction to go? > > Cheers, > Brad > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users From lists at ruby-forum.com Mon Aug 16 04:20:09 2010 From: lists at ruby-forum.com (Mike Howson) Date: Mon, 16 Aug 2010 10:20:09 +0200 Subject: [rspec-users] Module & Mixin testing strategy In-Reply-To: <1A67629C-C3A0-4946-A5AA-773C3BE80B89@patchspace.co.uk> References: <66a17881cd8be1321947088954978d4e@ruby-forum.com> <1A67629C-C3A0-4946-A5AA-773C3BE80B89@patchspace.co.uk> Message-ID: Wow - thanks very much Ashley & David for that very comprehensive response, you've answered my question and more! Cheers, Mike. -- Posted via http://www.ruby-forum.com/. From win at wincent.com Mon Aug 16 04:30:36 2010 From: win at wincent.com (Wincent Colaiuta) Date: Mon, 16 Aug 2010 10:30:36 +0200 Subject: [rspec-users] rspec command for rspec-2.0.0.beta.19 In-Reply-To: References: <1b3ad1b2-488f-4b7d-a9ff-1ac60e1bba20@p12g2000prn.googlegroups.com> Message-ID: <2BF9234B-5356-4DA9-9F17-846EC55EB465@wincent.com> El 16/08/2010, a las 06:39, David Chelimsky escribi?: > On Tue, Aug 10, 2010 at 11:17 AM, Brad Pauly wrote: >> I've just uninstalled all versions of rspec and installed >> rspec-2.0.0.beta.19 and rspec-rails-2.0.0.beta.19 for a rails project >> and I can't find the rspec command. Based on what bundler is telling >> me, I think it should be in: /usr/local/lib/ruby/gems/1.8/gems/bin/ >> but it isn't. >> >> $ bundle show rspec >> /usr/local/lib/ruby/gems/1.8/gems/rspec-2.0.0.beta.19 >> >> Everything seems to have installed properly with "bundle install" >> >> $ bundle show | grep rspec >> * rspec (2.0.0.beta.19) >> * rspec-core (2.0.0.beta.19) >> * rspec-expectations (2.0.0.beta.19) >> * rspec-mocks (2.0.0.beta.19) >> * rspec-rails (2.0.0.beta.19) >> >> Anyone have ideas on where I should be looking or a direction to go? > > If bundler installs it, then you have to run it under 'bundle exec': > > bundle exec rspec > > I've got an alias set up so I can say: > > be rspec spec > > There's something metaphysically pleasing about that. You can also have Bundler install binstubs in your project root using "bundle install --binstubs", which means you can do this when you're in your project root: bin/rspec spec Cheers, Wincent From matt at mattwynne.net Mon Aug 16 05:10:58 2010 From: matt at mattwynne.net (Matt Wynne) Date: Mon, 16 Aug 2010 10:10:58 +0100 Subject: [rspec-users] Including modules for view test in RSpec 2.0.0.beta.19 In-Reply-To: References: <32ce25e8-bb46-407b-b8a9-d30a39f02e75@j8g2000yqd.googlegroups.com> Message-ID: On 16 Aug 2010, at 05:48, David Chelimsky wrote: > 20) which will be sometime in the next week or so. Would have been > sooner, but I just got the book back from indexing (w0000t) and I have > some work to do before it goes off to the copyeditor (double w00000t). Congratulations David! cheers, Matt http://blog.mattwynne.net +44(0)7974 430184 From dchelimsky at gmail.com Mon Aug 16 07:22:23 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 16 Aug 2010 06:22:23 -0500 Subject: [rspec-users] 2.0.0.beta.19 installation problem In-Reply-To: References: Message-ID: <7A047B73-753C-45DC-8671-F3BE6C0A290C@gmail.com> On Aug 13, 2010, at 11:33 PM, Craig Castelaz wrote: > I purchased the beta version of the PragBook yesterday, but didn't get > a chance to begin reading until tonight. I'm currently stuck on > installing rspec. > > ~$ sudo gem install rspec --version 2.0.0.beta.19 > ************************************************** > Thank you for installing rspec-core-2.0.0.beta.19 > Please be sure to look at Upgrade.markdown to see what might have changed > since the last release. > ************************************************** > ************************************************** > Thank you for installing rspec-expectations-2.0.0.beta.19 > ************************************************** > ************************************************** > Thank you for installing rspec-mocks-2.0.0.beta.19 > ************************************************** > ERROR: Error installing rspec: > rspec requires rspec-core (= 2.0.0.beta.19, runtime) > > I'm a bit mystified because the process begins by installing > rspec-core-2.0.0.beta.19, but ends by telling me rspec-core > (2.0.0.beta.19) is required. I'm running Ruby 1.8.7 on OS 10.6.4 if > that's of any help. What version of rubygems do you have installed? If anything less than 1.3.7, please upgrade. Previous versions had some issues related to prerelease dependencies, but they've all been fixed in 1.3.7. HTH, David > Thanks, > Craig > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users From lists at ruby-forum.com Mon Aug 16 08:23:30 2010 From: lists at ruby-forum.com (Amit Kulkarni) Date: Mon, 16 Aug 2010 14:23:30 +0200 Subject: [rspec-users] Load dummy data using Factory girl Message-ID: <098d9c77fd27d90decd1524b7e336f5d@ruby-forum.com> Hello, I wanted to know how to load dummy data in the application using Factory girl. I had done this using Fixtures.I had made a fixtures folder into the test folder and run the command "rake test fixtures:load" Currently i tried using factories in the spec which is working fine. Wanted to know know regarding loading dummy data. -- Posted via http://www.ruby-forum.com/. From hayafirst at gmail.com Mon Aug 16 12:03:31 2010 From: hayafirst at gmail.com (Yi Wen) Date: Mon, 16 Aug 2010 11:03:31 -0500 Subject: [rspec-users] html formatter Message-ID: <65D5E55C-E40F-45D2-8E57-BF389E5153D0@GMAIL.COM> For rspec 2.0, is there anyway we can specify which file the output should be written into when using html formatter easily? Thanks Yi From myron.marston at gmail.com Mon Aug 16 12:26:11 2010 From: myron.marston at gmail.com (Myron Marston) Date: Mon, 16 Aug 2010 09:26:11 -0700 (PDT) Subject: [rspec-users] Name collision - how would you handle this? In-Reply-To: References: <958F356A-6B8F-49FF-B89E-C4557E943B2E@gmail.com> <13E563D1-9C62-4C75-A825-7D57F8C166DE@mattwynne.net> <6972E490-0BCD-4225-A9B4-BFA06ECA972A@mattwynne.net> <3D0F0C84-8692-4346-A97C-CFC6AFEF5599@gmail.com> <68723cef-41b2-4ea8-9316-3b666b23cce8@x24g2000pro.googlegroups.com> <83B6D23A-0CF6-4813-8A4C-BDCC9690100E@gmail.com> Message-ID: <7ff8813d-d1b9-4ba1-969d-66190d49e68c@p12g2000prn.googlegroups.com> > I think they should all be registered in the same place, in rspec-core. Or are you saying that rspec-rails would take the responsibility of registering the names for rspec-rails, rails, test/unit and minitest? That makes sense to me, as long as they're all using RSpec::Core::register_reserved_name (or whatever). My suggestion is that rspec-rails would be responsible for registering the names for rspec-rails and rails. Since test/unit and minitest can conceivably be used with RSpec outside of rails, I think it makes sense to make rspec-core responsible for registering the names for them. I think everything that deals with this (including rspec-core itself) would go through the RSpec::Core::register_reserved_name API (or whatever we call it). > I'm still not sold on this idea yet. Seems like a lot of complexity for not much benefit. I've already taken care of the message issue by encapsulating the assertion libs in a separate scope. I see two categories of reserved methods: 1. Methods like should and should_not. It would cause a problem if someone knowingly overwrote these as it would cause specs like "it { should do_something }" to fail, but it's pretty obvious that these methods are reserved, and unlikely that someone would need one of these as a helper method. 2. Methods like message, where it's _not_ obvious that it's a reserved method, and it's likely that someone will define this as a helper method. If all of the remaining reserved methods fall into the first category, then I think that there really isn't much need to add this. If we have any remaining reserved methods in the second category, then I think we should either solve it by refactoring code to remove the name collision (as you did) or implement something like what I've suggested. For now we can hold off on this, and revisit if we ever learn of any more reserved methods in the 2nd category. From kmandrup.github at gmail.com Mon Aug 16 14:13:26 2010 From: kmandrup.github at gmail.com (Kristian Mandrup) Date: Mon, 16 Aug 2010 11:13:26 -0700 (PDT) Subject: [rspec-users] RSpec 2 matchers 'code-spec' and 'file-spec' released Message-ID: Spec your generated Ruby code files code-spec at: http://github.com/kristianmandrup/code-spec Spec your file structure (files, dirs, symlinks) file-spec at: http://github.com/kristianmandrup/file-spec More to come... From rockrep at gmail.com Tue Aug 17 13:46:54 2010 From: rockrep at gmail.com (Michael Kintzer) Date: Tue, 17 Aug 2010 10:46:54 -0700 (PDT) Subject: [rspec-users] Possible improvements to routing spec API In-Reply-To: <6B6077A7-C771-40E3-AEDE-AD2BA696F703@wincent.com> References: <34C36264-CDA4-4767-9C21-58997B09C279@gmail.com> <9E8FA04F-8027-424B-BBC8-60AC667B79FC@wincent.com> <75BD8DC7-90E0-403F-9E6E-F64BD0D4BEAD@wincent.com> <0B3036BC-EA78-46C8-BF13-DC568A9E7864@wincent.com> <6B6077A7-C771-40E3-AEDE-AD2BA696F703@wincent.com> Message-ID: Lots of good proposals here. I would at least like to chime in that I agree with the goals as set out by Wincent below, and from a readability standpoint have preferred the API as suggested by Trevor. -Michael On Jul 7, 11:25?pm, Wincent Colaiuta wrote: > > So, when I see this kind of thing, I think _what_ are we trying to achieve in ourroutingspecs and _why_? At least for me, the answers are: > > ? 1. Confirm: To confirm that the routes I've defined actually do what I think they do > > ? 2. Describe: To serve as a complete, explicit, readable specification of the behavior I expect from my routes > > And finally: > > ? 3. That the Railsroutingcode actually works as advertised > > This last one is a bit dubious, but the truth is the Rails 3 router is a complete re-write and bugs in it and incompatibilities with the old router are being found and squished constantly. An exhaustive set ofroutingspecs can definitely help to uncover undiscovered edge cases. > > So, bearing in mind those goals, what I actually need from RSpec in order to achieve them is: > > ? - most importantly, a way of asserting that a user action (eg. HTTP verb + path + params) gets routed to a given controller + action with certain additional parameters (ie. a wrapper for assert_recognizes) > > ? - less importantly, a way of asserting that a set of params (action, controller, additional params) generates a particular path (ie. a wrapper for assert_generates); this is less important for me because in practice close to all (98%) of my URL generation is done with named URL helpers, and I can test those explicitly if I want > > ? - as syntactic sugar, a way of combining the above two assertions into one for those cases where the mapping is perfectly bidirectional (ie. a wrapper for assert_routing). > > With these tools I can achieve pretty much everything I need: not only test that user actions end up hitting the right spots in my application, but also specify clearly and explicitly what I expect those mappings to be. > > So for me, anything else doesn't really help me achieve my goals. The "have_resource(s)" matcher, for instance, doesn't help me and in fact actually undermines my goal of providing a complete and explicit specification of how my routes work. > > The "recognize" and "generate" matchers you suggest obviously are "on target" to help me fulfill my goals. Of these, the "recognize" one is the most important one though. > > Of the "match" and "get" matchers you suggest, seeing as they both wrap the same thing (assert_routing), one of them would have to go. I'd probably ditch "match" because it is just a repetition of the router DSL method of the same name, and my goal here isn't just to repeat that DSL in my specs. > > In fact, if you look at my most important goal -- asserting that a user action (HTTP verb, path, params) hits a specific end point (controller + action + additional params) -- you'll understand why, in my proposal, all of my specifications start with "get"/"post" etc followed by path, params and then controller/action. It's not just for resonance with other parts of RSpec like where we use "get" etc in controller specs. > > But if the goal is just to wrap the 3 Rails assertions as faithfully as possible, then you wind up with a different proposal. What David has posted is probably the closest to this goal. > > And if the goal is make the specs map as closely as possible onto the language of config/routes.rb, then you wind up with a different proposal still... (ie. the one you just made). > > So, I guess what I'm saying here is I'd like to hear _what_ people are wanting to achieve in theirroutingspecs and _why_; and then to ask what kind of means RSpec should provide to best achieve those goals. > > Cheers, > Wincent > > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users From craig.castelaz at gmail.com Tue Aug 17 20:12:55 2010 From: craig.castelaz at gmail.com (Craig Castelaz) Date: Tue, 17 Aug 2010 20:12:55 -0400 Subject: [rspec-users] Difficulties install Rspec Message-ID: I recently purchased the beta of the Rspec PragBook, and am really looking forward to diving in. Unfortunately, I'm having difficulty installing Rspec. I'm currently running Ruby 1.8.7 on Snow Leopard (10.6.4). Both Ruby itself, and Gem, appear to be working fine. However, the following is displayed whenever I attempt to install Rspec. ~$ sudo gem install rspec --version 2.0.0.beta.19 ************************************************** Thank you for installing rspec-core-2.0.0.beta.19 Please be sure to look at Upgrade.markdown to see what might have changed since the last release. ************************************************** ************************************************** Thank you for installing rspec-expectations-2.0.0.beta.19 ************************************************** ************************************************** Thank you for installing rspec-mocks-2.0.0.beta.19 ************************************************** ERROR: Error installing rspec: rspec requires rspec-core (= 2.0.0.beta.19, runtime) What I find really weird is that rspec-core seems to install at the beginning of the process, but then can't be found at the end. I did a quick scan of the archive and didn't see anything addressing this problem. (My apologies if I missed it.) Any help would be greatly appreciated. Thanks, Craig From nils.riedemann at gmail.com Tue Aug 17 04:18:42 2010 From: nils.riedemann at gmail.com (Nils Riedemann) Date: Tue, 17 Aug 2010 01:18:42 -0700 (PDT) Subject: [rspec-users] Autotest doesn't load up rspec (rspec2, rails3, ruby 1.9.2) Message-ID: Hi there, When i run `rspec --drb spec` everything works fine. Yet, when i want to use `autotest` it outputs the following: ~/code/ffr[master]% autotest /Users/nilsriedemann/.rvm/rubies/ruby-1.9.2-rc2/lib/ruby/1.9.1/ rubygems.rb:1051: warning: method redefined; discarding old gem :15: warning: previous definition of gem was here loading autotest/rails The contents of my ./autotest/discover.rb: Autotest.add_discovery { "rspec2" } Autotest.add_discovery { "rails" } (btw: `autospec` does not work at all? but that's a different story i think.) From dchelimsky at gmail.com Wed Aug 18 01:29:24 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 18 Aug 2010 00:29:24 -0500 Subject: [rspec-users] Autotest doesn't load up rspec (rspec2, rails3, ruby 1.9.2) In-Reply-To: References: Message-ID: <0ED42570-6FD5-4565-A093-517D3FDAE4F8@gmail.com> On Aug 17, 2010, at 3:18 AM, Nils Riedemann wrote: > Hi there, > > When i run `rspec --drb spec` everything works fine. Yet, when i want > to use `autotest` it outputs the following: > > ~/code/ffr[master]% autotest > /Users/nilsriedemann/.rvm/rubies/ruby-1.9.2-rc2/lib/ruby/1.9.1/ > rubygems.rb:1051: warning: method redefined; discarding old gem > :15: warning: previous definition of gem was > here > loading autotest/rails > > The contents of my ./autotest/discover.rb: > > Autotest.add_discovery { "rspec2" } > Autotest.add_discovery { "rails" } > > > (btw: `autospec` does not work at all? but that's a different story i > think.) Autospec is gone. See http://blog.davidchelimsky.net/2010/03/15/rspec-2-and-autotest/. Have you installed the autotest-rails gem? What's in your Gemfile? From ashley.moran at patchspace.co.uk Wed Aug 18 03:45:18 2010 From: ashley.moran at patchspace.co.uk (Ashley Moran) Date: Wed, 18 Aug 2010 08:45:18 +0100 Subject: [rspec-users] How do you turn colour on in autotest? Message-ID: <42B37239-A497-4A39-B412-159A50DA856D@patchspace.co.uk> Hi This may sound like a really dumb question (most likely because it is), but I have two RSpec 2 projects, and one of them gives me colour, but the other doesn't. Nothing in spec_helper.rb or my autotest files mentions colour. There's no spec.opts. So what could be different about them? Cheers Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran From nils.riedemann at gmail.com Wed Aug 18 04:56:13 2010 From: nils.riedemann at gmail.com (Nils Riedemann) Date: Wed, 18 Aug 2010 01:56:13 -0700 (PDT) Subject: [rspec-users] Autotest doesn't load up rspec (rspec2, rails3, ruby 1.9.2) In-Reply-To: <0ED42570-6FD5-4565-A093-517D3FDAE4F8@gmail.com> References: <0ED42570-6FD5-4565-A093-517D3FDAE4F8@gmail.com> Message-ID: On 18 Aug., 07:29, David Chelimsky wrote: > On Aug 17, 2010, at 3:18 AM, Nils Riedemann wrote: > > > > > > > Hi there, > > > When i run `rspec --drb spec` everything works fine. Yet, when i want > > to use `autotest` it outputs the following: > > > ? ?~/code/ffr[master]% autotest > > ? ?/Users/nilsriedemann/.rvm/rubies/ruby-1.9.2-rc2/lib/ruby/1.9.1/ > > rubygems.rb:1051: warning: method redefined; discarding old gem > > ? ?:15: warning: previous definition of gem was > > here > > ? ?loading autotest/rails > > > The contents of my ./autotest/discover.rb: > > > ? ?Autotest.add_discovery { "rspec2" } > > ? ?Autotest.add_discovery { "rails" } > > > (btw: `autospec` does not work at all? but that's a different story i > > think.) > > Autospec is gone. Seehttp://blog.davidchelimsky.net/2010/03/15/rspec-2-and-autotest/. > > Have you installed the autotest-rails gem? What's in your Gemfile? > > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users I have autotest-rails (4.1.0) installed. My Gemfile: source 'http://rubygems.org' gem 'rails', '3.0.0.rc' # Bundle edge Rails instead: # gem 'rails', :git => 'git://github.com/rails/rails.git' gem 'mysql' # gem 'sqlite3-ruby', :require => 'sqlite3' # Use unicorn as the web server # gem 'unicorn' # Deploy with Capistrano gem 'capistrano' # To use debugger # gem 'ruby-debug' # Bundle the extra gems: # gem 'bj' # gem 'nokogiri', '1.4.1' # gem 'sqlite3-ruby', :require => 'sqlite3' # gem 'aws-s3', :require => 'aws/s3' gem "geokit", '>= 1.5.0' # Bundle gems for the local environment. Make sure to # put test-only gems in this group so their generators # and rake tasks are available in development mode: group :development, :test do gem 'rspec', ">= 2.0.0.beta.18" gem 'rspec-rails', ">= 2.0.0.beta.18" gem 'factory_girl_rails' gem 'shoulda' gem 'spork' gem 'webrat' end group :test do gem 'rspec', ">= 2.0.0.beta.18" gem 'rspec-rails', ">= 2.0.0.beta.18" gem 'factory_girl_rails' gem 'shoulda' gem 'spork' gem 'webrat' end From lists at ruby-forum.com Wed Aug 18 08:21:46 2010 From: lists at ruby-forum.com (Amit Kulkarni) Date: Wed, 18 Aug 2010 14:21:46 +0200 Subject: [rspec-users] Testing Email thriugh Rspec In-Reply-To: References: <59890594d0de59b0496d0010538b7cef@ruby-forum.com> <4356a8c4fbe02d499f9b3d2bdb5fe4a3@ruby-forum.com> <547f2fe7007020c5b75cf9a7365de1df@ruby-forum.com> Message-ID: <1aad5813dc71481ee0bebf2a78ec898f@ruby-forum.com> jko170 wrote: > There is also the excellent email_spec gem: > > http://github.com/bmabey/email-spec/ Continuing with the topic but scenario is different: I had written a rake task in rspec.rake.What i want is after running the task i should get an email So for that i have created a method in app/models/notifier.rb which is as follows: def sanity @recipients = "amit at test.com" @subject = "Sanity" end Now in the rake task i am calling the method which is a follows (I am writing this rake task under rspec.rake): desc "Sanity testing" Spec::Rake::SpecTask.new(:sanity) do |t| # t.spec_opts = ["--format", "specdoc", "--dry-run"] t.spec_files = FileList['spec/models/sanity_spec.rb'] Notifier.deliver_sanity end But if i run the task it says "uninitialized constant Notifier" .If i comment the notifier line then my rake task is working fine. May be it is not getting the model.So do i need to add the model or some configuration need to be done -- Posted via http://www.ruby-forum.com/. From dchelimsky at gmail.com Wed Aug 18 09:24:20 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 18 Aug 2010 08:24:20 -0500 Subject: [rspec-users] Testing Email thriugh Rspec In-Reply-To: <1aad5813dc71481ee0bebf2a78ec898f@ruby-forum.com> References: <59890594d0de59b0496d0010538b7cef@ruby-forum.com> <4356a8c4fbe02d499f9b3d2bdb5fe4a3@ruby-forum.com> <547f2fe7007020c5b75cf9a7365de1df@ruby-forum.com> <1aad5813dc71481ee0bebf2a78ec898f@ruby-forum.com> Message-ID: On Aug 18, 2010, at 7:21 AM, Amit Kulkarni wrote: > jko170 wrote: >> There is also the excellent email_spec gem: >> >> http://github.com/bmabey/email-spec/ > > Continuing with the topic but scenario is different: > I had written a rake task in rspec.rake.What i want is after running the > task i should get an email > So for that i have created a method in app/models/notifier.rb which is > as follows: > def sanity > @recipients = "amit at test.com" > @subject = "Sanity" > end > > Now in the rake task i am calling the method which is a follows (I am > writing this rake task under rspec.rake): > desc "Sanity testing" > Spec::Rake::SpecTask.new(:sanity) do |t| > # t.spec_opts = ["--format", "specdoc", "--dry-run"] > t.spec_files = FileList['spec/models/sanity_spec.rb'] > Notifier.deliver_sanity > end What are you actually trying to accomplish here? Is this a means of manually testing that the email gets sent? Or does the email really need to get sent when running rake tasks for some business purpose other than testing? > But if i run the task it says "uninitialized constant Notifier" .If i > comment the notifier line then my rake task is working fine. > May be it is not getting the model.So do i need to add the model or some > configuration need to be done I think that's pretty clear from the error message. Cheers, David From dchelimsky at gmail.com Wed Aug 18 09:28:43 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 18 Aug 2010 08:28:43 -0500 Subject: [rspec-users] Autotest doesn't load up rspec (rspec2, rails3, ruby 1.9.2) In-Reply-To: References: <0ED42570-6FD5-4565-A093-517D3FDAE4F8@gmail.com> Message-ID: <852621D6-E5EC-457D-94AC-7293F42D0F21@gmail.com> On Aug 18, 2010, at 3:56 AM, Nils Riedemann wrote: > > On 18 Aug., 07:29, David Chelimsky wrote: >> On Aug 17, 2010, at 3:18 AM, Nils Riedemann wrote: >> >> >> >> >> >>> Hi there, >> >>> When i run `rspec --drb spec` everything works fine. Yet, when i want >>> to use `autotest` it outputs the following: >> >>> ~/code/ffr[master]% autotest >>> /Users/nilsriedemann/.rvm/rubies/ruby-1.9.2-rc2/lib/ruby/1.9.1/ >>> rubygems.rb:1051: warning: method redefined; discarding old gem >>> :15: warning: previous definition of gem was >>> here >>> loading autotest/rails >> >>> The contents of my ./autotest/discover.rb: >> >>> Autotest.add_discovery { "rspec2" } >>> Autotest.add_discovery { "rails" } >> >>> (btw: `autospec` does not work at all? but that's a different story i >>> think.) >> >> Autospec is gone. Seehttp://blog.davidchelimsky.net/2010/03/15/rspec-2-and-autotest/. >> >> Have you installed the autotest-rails gem? What's in your Gemfile? >> >> _______________________________________________ >> rspec-users mailing list >> rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users > > I have autotest-rails (4.1.0) installed. My Gemfile: > > source 'http://rubygems.org' > > gem 'rails', '3.0.0.rc' > > # Bundle edge Rails instead: > # gem 'rails', :git => 'git://github.com/rails/rails.git' > > gem 'mysql' > # gem 'sqlite3-ruby', :require => 'sqlite3' > > # Use unicorn as the web server > # gem 'unicorn' > > # Deploy with Capistrano > gem 'capistrano' > > # To use debugger > # gem 'ruby-debug' > > # Bundle the extra gems: > # gem 'bj' > # gem 'nokogiri', '1.4.1' > # gem 'sqlite3-ruby', :require => 'sqlite3' > # gem 'aws-s3', :require => 'aws/s3' > gem "geokit", '>= 1.5.0' > > # Bundle gems for the local environment. Make sure to > # put test-only gems in this group so their generators > # and rake tasks are available in development mode: > group :development, :test do > gem 'rspec', ">= 2.0.0.beta.18" > gem 'rspec-rails', ">= 2.0.0.beta.18" > gem 'factory_girl_rails' > gem 'shoulda' > gem 'spork' > gem 'webrat' > end > > group :test do > gem 'rspec', ">= 2.0.0.beta.18" > gem 'rspec-rails', ">= 2.0.0.beta.18" > gem 'factory_girl_rails' > gem 'shoulda' > gem 'spork' > gem 'webrat' > end I don't think this is the source of your issue, but why do you have all of the testing related gems duplicated? Also, beta 18 doesn't work with rails-3.0.0.rc, so that should say ">= 2.0.0.beta.19" As for this issue, I'm not sure what else is up. Is anybody else on this list having a similar issue? From dchelimsky at gmail.com Wed Aug 18 09:31:20 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 18 Aug 2010 08:31:20 -0500 Subject: [rspec-users] Autotest doesn't load up rspec (rspec2, rails3, ruby 1.9.2) In-Reply-To: <852621D6-E5EC-457D-94AC-7293F42D0F21@gmail.com> References: <0ED42570-6FD5-4565-A093-517D3FDAE4F8@gmail.com> <852621D6-E5EC-457D-94AC-7293F42D0F21@gmail.com> Message-ID: On Aug 18, 2010, at 8:28 AM, David Chelimsky wrote: > On Aug 18, 2010, at 3:56 AM, Nils Riedemann wrote: > >> >> On 18 Aug., 07:29, David Chelimsky wrote: >>> On Aug 17, 2010, at 3:18 AM, Nils Riedemann wrote: >>> >>> >>> >>> >>> >>>> Hi there, >>> >>>> When i run `rspec --drb spec` everything works fine. Yet, when i want >>>> to use `autotest` it outputs the following: >>> >>>> ~/code/ffr[master]% autotest >>>> /Users/nilsriedemann/.rvm/rubies/ruby-1.9.2-rc2/lib/ruby/1.9.1/ >>>> rubygems.rb:1051: warning: method redefined; discarding old gem >>>> :15: warning: previous definition of gem was >>>> here >>>> loading autotest/rails >>> >>>> The contents of my ./autotest/discover.rb: >>> >>>> Autotest.add_discovery { "rspec2" } >>>> Autotest.add_discovery { "rails" } >>> >>>> (btw: `autospec` does not work at all? but that's a different story i >>>> think.) >>> >>> Autospec is gone. Seehttp://blog.davidchelimsky.net/2010/03/15/rspec-2-and-autotest/. >>> >>> Have you installed the autotest-rails gem? What's in your Gemfile? >>> >>> _______________________________________________ >>> rspec-users mailing list >>> rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users >> >> I have autotest-rails (4.1.0) installed. My Gemfile: >> >> source 'http://rubygems.org' >> >> gem 'rails', '3.0.0.rc' >> >> # Bundle edge Rails instead: >> # gem 'rails', :git => 'git://github.com/rails/rails.git' >> >> gem 'mysql' >> # gem 'sqlite3-ruby', :require => 'sqlite3' >> >> # Use unicorn as the web server >> # gem 'unicorn' >> >> # Deploy with Capistrano >> gem 'capistrano' >> >> # To use debugger >> # gem 'ruby-debug' >> >> # Bundle the extra gems: >> # gem 'bj' >> # gem 'nokogiri', '1.4.1' >> # gem 'sqlite3-ruby', :require => 'sqlite3' >> # gem 'aws-s3', :require => 'aws/s3' >> gem "geokit", '>= 1.5.0' >> >> # Bundle gems for the local environment. Make sure to >> # put test-only gems in this group so their generators >> # and rake tasks are available in development mode: >> group :development, :test do >> gem 'rspec', ">= 2.0.0.beta.18" >> gem 'rspec-rails', ">= 2.0.0.beta.18" >> gem 'factory_girl_rails' >> gem 'shoulda' >> gem 'spork' >> gem 'webrat' >> end >> >> group :test do >> gem 'rspec', ">= 2.0.0.beta.18" >> gem 'rspec-rails', ">= 2.0.0.beta.18" >> gem 'factory_girl_rails' >> gem 'shoulda' >> gem 'spork' >> gem 'webrat' >> end > > I don't think this is the source of your issue, but why do you have all of the testing related gems duplicated? Also, beta 18 doesn't work with rails-3.0.0.rc, so that should say ">= 2.0.0.beta.19" > > As for this issue, I'm not sure what else is up. Is anybody else on this list having a similar issue? FYI - I've been able to reproduce the issue - but I'm not sure what the problem is yet and I'm off for the day. Would you mind posting this as an issue to github? http://github.com/rspec/rspec-rails/issues. Cheers, David From cflipse at gmail.com Wed Aug 18 10:06:24 2010 From: cflipse at gmail.com (Chris Flipse) Date: Wed, 18 Aug 2010 10:06:24 -0400 Subject: [rspec-users] How do you turn colour on in autotest? In-Reply-To: <42B37239-A497-4A39-B412-159A50DA856D@patchspace.co.uk> References: <42B37239-A497-4A39-B412-159A50DA856D@patchspace.co.uk> Message-ID: Check for a .rspec file in one project, not the other. On Wed, Aug 18, 2010 at 3:45 AM, Ashley Moran wrote: > Hi > > This may sound like a really dumb question (most likely because it is), but > I have two RSpec 2 projects, and one of them gives me colour, but the other > doesn't. Nothing in spec_helper.rb or my autotest files mentions colour. > There's no spec.opts. So what could be different about them? > > Cheers > Ash > > -- > http://www.patchspace.co.uk/ > http://www.linkedin.com/in/ashleymoran > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > -- // anything worth taking seriously is worth making fun of // http://blog.devcaffeine.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ashley.moran at patchspace.co.uk Wed Aug 18 10:59:58 2010 From: ashley.moran at patchspace.co.uk (Ashley Moran) Date: Wed, 18 Aug 2010 15:59:58 +0100 Subject: [rspec-users] How do you turn colour on in autotest? In-Reply-To: References: <42B37239-A497-4A39-B412-159A50DA856D@patchspace.co.uk> Message-ID: On 18 Aug 2010, at 15:06, Chris Flipse wrote: > Check for a .rspec file in one project, not the other. Aha! You're a genius :D I need to stop TextMate hiding stuff like that... Cheers Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran From lists at ruby-forum.com Wed Aug 18 11:45:34 2010 From: lists at ruby-forum.com (Amit Kulkarni) Date: Wed, 18 Aug 2010 17:45:34 +0200 Subject: [rspec-users] Testing Email thriugh Rspec In-Reply-To: References: <59890594d0de59b0496d0010538b7cef@ruby-forum.com> <4356a8c4fbe02d499f9b3d2bdb5fe4a3@ruby-forum.com> <547f2fe7007020c5b75cf9a7365de1df@ruby-forum.com> <1aad5813dc71481ee0bebf2a78ec898f@ruby-forum.com> Message-ID: <732024485214188408d206203e430a14@ruby-forum.com> For the application i have written scripts which i am call from a rake task. So i need to know whether how much tests have been passed/failed by email. -- Posted via http://www.ruby-forum.com/. From lists at ruby-forum.com Wed Aug 18 11:46:04 2010 From: lists at ruby-forum.com (Amit Kulkarni) Date: Wed, 18 Aug 2010 17:46:04 +0200 Subject: [rspec-users] Load dummy data using Factory girl In-Reply-To: <098d9c77fd27d90decd1524b7e336f5d@ruby-forum.com> References: <098d9c77fd27d90decd1524b7e336f5d@ruby-forum.com> Message-ID: <2786b0e71c828d24c049f589be99273e@ruby-forum.com> Amit Kulkarni wrote: > Hello, > I wanted to know how to load dummy data in the application using Factory > girl. > I had done this using Fixtures.I had made a fixtures folder into the > test folder and run the command "rake test fixtures:load" > Currently i tried using factories in the spec which is working fine. > Wanted to know know regarding loading dummy data. Any updates... -- Posted via http://www.ruby-forum.com/. From dchelimsky at gmail.com Wed Aug 18 11:50:14 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 18 Aug 2010 10:50:14 -0500 Subject: [rspec-users] Load dummy data using Factory girl In-Reply-To: <2786b0e71c828d24c049f589be99273e@ruby-forum.com> References: <098d9c77fd27d90decd1524b7e336f5d@ruby-forum.com> <2786b0e71c828d24c049f589be99273e@ruby-forum.com> Message-ID: <690126E8-9E85-4FAA-BA11-7851482BFBD9@gmail.com> On Aug 18, 2010, at 10:46 AM, Amit Kulkarni wrote: > Amit Kulkarni wrote: >> Hello, >> I wanted to know how to load dummy data in the application using Factory >> girl. >> I had done this using Fixtures.I had made a fixtures folder into the >> test folder and run the command "rake test fixtures:load" >> Currently i tried using factories in the spec which is working fine. >> Wanted to know know regarding loading dummy data. > > Any updates... This is something I've never done before. Have you tried the factory girl list? http://groups.google.com/group/factory_girl From rogerpack2005 at gmail.com Wed Aug 18 12:31:04 2010 From: rogerpack2005 at gmail.com (rogerdpack) Date: Wed, 18 Aug 2010 09:31:04 -0700 (PDT) Subject: [rspec-users] dynamic tests possible? Message-ID: Sorry if this is a newbie question, but here goes. I was wondering if the following is somehow possible: for file in Dir['*.bmp'] it "should be able to parse #{file}" do p file # test this file end end Currently rspec seems to evaluate the blocks after the fact, leading to "file" always being the last file in the list. I was unsure how to pass a parameter into an "it" block. Thoughts? Thanks. -r From dchelimsky at gmail.com Wed Aug 18 12:38:32 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 18 Aug 2010 11:38:32 -0500 Subject: [rspec-users] dynamic tests possible? In-Reply-To: References: Message-ID: On Aug 18, 2010, at 11:31 AM, rogerdpack wrote: > Sorry if this is a newbie question, but here goes. > > I was wondering if the following is somehow possible: > > > for file in Dir['*.bmp'] Use this instead: Dir["*.bmp"].each do |file| > it "should be able to parse #{file}" do > p file > # test this file > end > end > > Currently rspec seems to evaluate the blocks after the fact, leading > to "file" always being the last file in the list. > I was unsure how to pass a parameter into an "it" block. > Thoughts? > Thanks. > -r From dchelimsky at gmail.com Wed Aug 18 13:11:31 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 18 Aug 2010 12:11:31 -0500 Subject: [rspec-users] dynamic tests possible? In-Reply-To: References: Message-ID: On Aug 18, 2010, at 11:38 AM, David Chelimsky wrote: > > On Aug 18, 2010, at 11:31 AM, rogerdpack wrote: > >> Sorry if this is a newbie question, but here goes. >> >> I was wondering if the following is somehow possible: >> >> >> for file in Dir['*.bmp'] > > Use this instead: > > Dir["*.bmp"].each do |file| >> it "should be able to parse #{file}" do >> p file >> # test this file >> end >> end The reason, btw, has to do with ruby closures and scope. Ruby blocks are closures, which means they have access to the state of the scope in which they were defined, but they don't access that state until they are evaluated. By using an iterator that takes a block, we end up with two nested closures: [1,2,3].each do |n| it "is #{n}" do puts n end end Here, the first time through the outer iterator, the value of n is 1. The string passed to it() is evaluated at this time, so that string is transformed to "is 1". The block passed to it() is not eval'd yet, but when it does get evaluated it will take on the value of the scope in which it was defined, which the block passed to the iterator with its block parameter. This will maintain a value of 1. for n in [1,2,3] it "is #{n}" do puts n end end Here, the first time through the outer loop, the value of n is 1. Again, the string passed to it() is evaluated at this time, so that string is transformed to "is 1". When the block is eval'd, the scope in which it was defined is the same scope in which the loop was defined, so n will have changed to the last item in the list, 3. Does this make sense to you? Cheers, David >> >> Currently rspec seems to evaluate the blocks after the fact, leading >> to "file" always being the last file in the list. >> I was unsure how to pass a parameter into an "it" block. >> Thoughts? >> Thanks. >> -r > > From dmarkow at gmail.com Wed Aug 18 18:39:45 2010 From: dmarkow at gmail.com (Dylan Markow) Date: Wed, 18 Aug 2010 15:39:45 -0700 Subject: [rspec-users] RSpec 2/Rails 3 - content_for in view specs Message-ID: My main layout includes separate content_for/yield sections for my header, sidebar, footer, and content. However, when running a view spec, the `rendered` variable seems to only contain a string of just the primary content and ignores the header/footer/sidebar as well as the rest of my layout file (the "render" call just returns my primary content wrapped in generic and tags). Is there a way to get to the content captured in a "content_for" block through my view specs, or at the very least get my "render" call to use the full layout? I've tried doing a "render :layout => 'application'" which gives me: 1) contacts/show.html.erb shows a URL if the contact has one Failure/Error: render :layout => "application" undefined method `formats' for nil:NilClass # /home/dylan/.rvm/gems/ruby-1.9.2-p0/gems/activesupport-3.0.0.rc/lib/active_support/whiny_nil.rb:48:in `method_missing' # /home/dylan/.rvm/gems/ruby-1.9.2-p0/gems/actionpack-3.0.0.rc/lib/action_view/render/rendering.rb:25:in `render' # /home/dylan/.rvm/gems/ruby-1.9.2-p0/gems/actionpack-3.0.0.rc/lib/action_view/test_case.rb:103:in `render' # /home/dylan/.rvm/gems/ruby-1.9.2-p0/gems/rspec-rails-2.0.0.beta.19/lib/rspec/rails/example/view_example_group.rb:73:in `render' # ./spec/views/contacts/show.html.erb_spec.rb:20:in `block (2 levels) in
' I've also tried using response.capture(:sidebar), response[:sidebar], rendered.capture(:sidebar), rendered[:sidebar], view.capture(:sidebar), etc. and none of them worked -- they all give various errors. Here is my view spec that I'm trying to run: describe "contacts/show.html.erb" do it "shows a URL if present" do @contact = Factory(:complete_contact, :web_page => " http://www.example.com") # Using Factory Girl render rendered.should have_selector("span", :content => " http://www.example.com") end end Thank you! Dylan Markow dmarkow at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at ruby-forum.com Thu Aug 19 09:49:30 2010 From: lists at ruby-forum.com (Amit Kulkarni) Date: Thu, 19 Aug 2010 15:49:30 +0200 Subject: [rspec-users] Load dummy data using Factory girl In-Reply-To: <690126E8-9E85-4FAA-BA11-7851482BFBD9@gmail.com> References: <098d9c77fd27d90decd1524b7e336f5d@ruby-forum.com> <2786b0e71c828d24c049f589be99273e@ruby-forum.com> <690126E8-9E85-4FAA-BA11-7851482BFBD9@gmail.com> Message-ID: <881a3a26a1d45509ddf0c66bf48aa587@ruby-forum.com> David Chelimsky wrote: > On Aug 18, 2010, at 10:46 AM, Amit Kulkarni wrote: > >> Amit Kulkarni wrote: >>> Hello, >>> I wanted to know how to load dummy data in the application using Factory >>> girl. >>> I had done this using Fixtures.I had made a fixtures folder into the >>> test folder and run the command "rake test fixtures:load" >>> Currently i tried using factories in the spec which is working fine. >>> Wanted to know know regarding loading dummy data. >> >> Any updates... > > This is something I've never done before. Have you tried the factory > girl list? > > http://groups.google.com/group/factory_girl No,Will post it. Thanks. -- Posted via http://www.ruby-forum.com/. From lists at ruby-forum.com Thu Aug 19 09:57:24 2010 From: lists at ruby-forum.com (Amit Kulkarni) Date: Thu, 19 Aug 2010 15:57:24 +0200 Subject: [rspec-users] Testing Email thriugh Rspec In-Reply-To: <732024485214188408d206203e430a14@ruby-forum.com> References: <59890594d0de59b0496d0010538b7cef@ruby-forum.com> <4356a8c4fbe02d499f9b3d2bdb5fe4a3@ruby-forum.com> <547f2fe7007020c5b75cf9a7365de1df@ruby-forum.com> <1aad5813dc71481ee0bebf2a78ec898f@ruby-forum.com> <732024485214188408d206203e430a14@ruby-forum.com> Message-ID: <93e9322764a3826a3d2e3e5c3b2f7106@ruby-forum.com> Amit Kulkarni wrote: > For the application i have written scripts which i am call from a rake > task. > So i need to know whether how much tests have been passed/failed by > email. In the mail i will get the count of total tests passed/failed. -- Posted via http://www.ruby-forum.com/. From dchelimsky at gmail.com Thu Aug 19 10:09:40 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 19 Aug 2010 09:09:40 -0500 Subject: [rspec-users] Testing Email thriugh Rspec In-Reply-To: <93e9322764a3826a3d2e3e5c3b2f7106@ruby-forum.com> References: <59890594d0de59b0496d0010538b7cef@ruby-forum.com> <4356a8c4fbe02d499f9b3d2bdb5fe4a3@ruby-forum.com> <547f2fe7007020c5b75cf9a7365de1df@ruby-forum.com> <1aad5813dc71481ee0bebf2a78ec898f@ruby-forum.com> <732024485214188408d206203e430a14@ruby-forum.com> <93e9322764a3826a3d2e3e5c3b2f7106@ruby-forum.com> Message-ID: <528D3D07-173B-4D99-B991-8E5EBC8774E7@gmail.com> On Aug 19, 2010, at 8:57 AM, Amit Kulkarni wrote: > Amit Kulkarni wrote: >> For the application i have written scripts which i am call from a rake >> task. >> So i need to know whether how much tests have been passed/failed by >> email. > > In the mail i will get the count of total tests passed/failed. Please quote the relevant parts of the thread so we know what you're talking about. From lists at ruby-forum.com Thu Aug 19 10:34:33 2010 From: lists at ruby-forum.com (Amit Kulkarni) Date: Thu, 19 Aug 2010 16:34:33 +0200 Subject: [rspec-users] Testing Email thriugh Rspec In-Reply-To: <528D3D07-173B-4D99-B991-8E5EBC8774E7@gmail.com> References: <59890594d0de59b0496d0010538b7cef@ruby-forum.com> <4356a8c4fbe02d499f9b3d2bdb5fe4a3@ruby-forum.com> <547f2fe7007020c5b75cf9a7365de1df@ruby-forum.com> <1aad5813dc71481ee0bebf2a78ec898f@ruby-forum.com> <732024485214188408d206203e430a14@ruby-forum.com> <93e9322764a3826a3d2e3e5c3b2f7106@ruby-forum.com> <528D3D07-173B-4D99-B991-8E5EBC8774E7@gmail.com> Message-ID: David Chelimsky wrote: > On Aug 19, 2010, at 8:57 AM, Amit Kulkarni wrote: > >> Amit Kulkarni wrote: >>> For the application i have written scripts which i am call from a rake >>> task. >>> So i need to know whether how much tests have been passed/failed by >>> email. >> >> In the mail i will get the count of total tests passed/failed. > > Please quote the relevant parts of the thread so we know what you're > talking about. Actually what i want is when my rake task gets executed then i am calling a notifier_deliver method (which i have defined in app/models/notifier.rb) which will send mail. So i want to know how should i do this in Spec task.Since doing normally in separate rake file it works but it shows error in spec rake file i.e. in rspec.rake. -- Posted via http://www.ruby-forum.com/. From dchelimsky at gmail.com Thu Aug 19 11:19:05 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 19 Aug 2010 10:19:05 -0500 Subject: [rspec-users] Testing Email thriugh Rspec In-Reply-To: References: <59890594d0de59b0496d0010538b7cef@ruby-forum.com> <4356a8c4fbe02d499f9b3d2bdb5fe4a3@ruby-forum.com> <547f2fe7007020c5b75cf9a7365de1df@ruby-forum.com> <1aad5813dc71481ee0bebf2a78ec898f@ruby-forum.com> <732024485214188408d206203e430a14@ruby-forum.com> <93e9322764a3826a3d2e3e5c3b2f7106@ruby-forum.com> <528D3D07-173B-4D99-B991-8E5EBC8774E7@gmail.com> Message-ID: <57B4B596-A3F6-4C66-8FA9-24CEC08D8C9A@gmail.com> On Aug 19, 2010, at 9:34 AM, Amit Kulkarni wrote: > David Chelimsky wrote: >> On Aug 19, 2010, at 8:57 AM, Amit Kulkarni wrote: >> >>> Amit Kulkarni wrote: >>>> For the application i have written scripts which i am call from a rake >>>> task. >>>> So i need to know whether how much tests have been passed/failed by >>>> email. >>> >>> In the mail i will get the count of total tests passed/failed. >> >> Please quote the relevant parts of the thread so we know what you're >> talking about. > Actually what i want is when my rake task gets executed then i am > calling a notifier_deliver method (which i have defined in > app/models/notifier.rb) which will send mail. > So i want to know how should i do this in Spec task.Since doing normally > in separate rake file it works but it shows error in spec rake file i.e. > in rspec.rake. Let's try this again: >> Please quote the relevant parts of the thread so we know what you're >> talking about. To clarify: I'm asking you to help me help you by including the parts of this thread that will help provide context so I can answer you without having to go digging through my email archives. Earlier this thread you had examples of code and failure messages. I don't remember them exactly, but I remember they were there. Please send a single email that includes all of the relevant parts of this thread in one email so I (or anyone else on this list who offers help) don't have to go digging through email archives to piece this all together. Cheers, David From myron.marston at gmail.com Fri Aug 20 01:40:05 2010 From: myron.marston at gmail.com (Myron Marston) Date: Thu, 19 Aug 2010 22:40:05 -0700 (PDT) Subject: [rspec-users] Issue with parameterized shared example group on ruby 1.8.6 Message-ID: <619faada-4fa5-40c8-991a-968df21f3267@q40g2000prg.googlegroups.com> I've been refactoring the specs for my VCR gem[1] to take advantage of the new shared example group parameterization. VCR supports both FakeWeb and WebMock, with an appropriate adapter class implemented for each. The adapter classes have nearly identical behavior, except for the differences in the feature set of FakeWeb and WebMock. WebMock supports a bunch of HTTP libraries that FakeWeb doesn't, and also supports matching requests on request headers and body. My specs basically boil down to this: describe VCR::HttpStubbingAdapters::FakeWeb do it_should_behave_like 'an http stubbing adapter', ['net/http'], [:method, :uri, :host] end describe VCR::HttpStubbingAdapters::WebMock do it_should_behave_like 'an http stubbing adapter', %w[net/http patron httpclient em-http-request], [:method, :uri, :host, :body, :headers] end Basically, this is a shared example group that takes two parameters: an array of supported HTTP libraries, and an array of supported request match attributes. This design makes it easy to have a single shared example group that specs out the full behavior of both adapters. If I ever implement another adapter, it's very easy to spec it out this way, and pass arrays indicating the supported features. This works great on ruby 1.8.7 and above, but I'm getting an error on 1.8.6. This gist[2] demonstrates the error in far simpler form. The issue is due to the way I implemented module_eval_with_args on 1.8.6[3]. The lack of module_exec on 1.8.6 forced me to eval the block twice: once using instance_eval_with_args (so that the block is properly eval'd with arguments), and once with module_eval (so that we can extract the instance method definitions, in order to deal with the difference between module_eval and instance_eval). The error occurs in the module_eval: because it's not evaluated with any args, the methods we call on the args raise NoMethodErrors. Note that the "normal" use case of parameterized groups doesn't have this problem. shared_example_group_for :foo do |arg| it "can access the argument (#{arg}) in the doc string" { arg.should ... } end In this case, #it raises a no method error that is handled by our anonymous class. Plus the only method being called on the arg is #to_s, which is defined for every object. So this problem really only exists when you call methods on arguments that are not defined on Object, outside of the RSpec DSL methods. So...how should we deal with this? A few ideas come to mind: 1. Find a better way to fake module_exec on ruby 1.8.6. I'm not sure if this is even doable. 2. Leave things as they are...but I don't like this idea since the error message is fairly cryptic. 3. Rescue the error and raise a more clear error message. 4. Rescue the error and print a warning. I lean towards #4, because the #module_eval is only necessary to extract the instance method definitions. This error doesn't prohibit the shared example group from working on 1.8.6; as long as their are no instance method definitions, or the instance method definitions come before the error occurs, it can still work fine, I think. The warning can hopefully make it clear that you just need to put the instance method definitions first and everything will still work. The one really difficult part about options #3 and #4 is the wording of the waring/error: this is a fairly complex, nuanced error, and it's hard to boil it down into a sentence explaining the issue and how to fix it. Thoughts? Myron [1] http://github.com/myronmarston/vcr/commit/0f304c132eea7d0a7e32d6731e2557ce6805f31c [2] http://gist.github.com/539649 [3] http://github.com/rspec/rspec-core/blob/master/lib/rspec/core/extensions/module_eval_with_args.rb From lists at ruby-forum.com Fri Aug 20 02:51:52 2010 From: lists at ruby-forum.com (Amit Kulkarni) Date: Fri, 20 Aug 2010 08:51:52 +0200 Subject: [rspec-users] Testing Email thriugh Rspec In-Reply-To: <57B4B596-A3F6-4C66-8FA9-24CEC08D8C9A@gmail.com> References: <59890594d0de59b0496d0010538b7cef@ruby-forum.com> <4356a8c4fbe02d499f9b3d2bdb5fe4a3@ruby-forum.com> <547f2fe7007020c5b75cf9a7365de1df@ruby-forum.com> <1aad5813dc71481ee0bebf2a78ec898f@ruby-forum.com> <732024485214188408d206203e430a14@ruby-forum.com> <93e9322764a3826a3d2e3e5c3b2f7106@ruby-forum.com> <528D3D07-173B-4D99-B991-8E5EBC8774E7@gmail.com> <57B4B596-A3F6-4C66-8FA9-24CEC08D8C9A@gmail.com> Message-ID: Ok.I will post this topic separately.. :) -- Posted via http://www.ruby-forum.com/. From ashley.moran at patchspace.co.uk Fri Aug 20 03:33:18 2010 From: ashley.moran at patchspace.co.uk (Ashley Moran) Date: Fri, 20 Aug 2010 08:33:18 +0100 Subject: [rspec-users] Issue with parameterized shared example group on ruby 1.8.6 In-Reply-To: <619faada-4fa5-40c8-991a-968df21f3267@q40g2000prg.googlegroups.com> References: <619faada-4fa5-40c8-991a-968df21f3267@q40g2000prg.googlegroups.com> Message-ID: On 20 Aug 2010, at 06:40, Myron Marston wrote: > describe VCR::HttpStubbingAdapters::FakeWeb do > it_should_behave_like 'an http stubbing adapter', ['net/http'], > [:method, :uri, :host] > end > > describe VCR::HttpStubbingAdapters::WebMock do > it_should_behave_like 'an http stubbing adapter', %w[net/http patron > httpclient em-http-request], [:method, :uri, :host, :body, :headers] > end Neat! I'm interested to see applications of parameterised shared examples. I'd certainly never thought of defining optional features in that way. > So...how should we deal with this? A few ideas come to mind: > > 1. Find a better way to fake module_exec on ruby 1.8.6. I'm not sure > if this is even doable. > 2. Leave things as they are...but I don't like this idea since the > error message is fairly cryptic. > 3. Rescue the error and raise a more clear error message. > 4. Rescue the error and print a warning. > > I lean towards #4, because the #module_eval is only necessary to > extract the instance method definitions. 4 makes sense to me iff the code does actually run correctly in all circumstances, otherwise I'd lean towards 3. Ash -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashleymoran From george.jquery at SoftwareUnity.com Fri Aug 20 04:36:11 2010 From: george.jquery at SoftwareUnity.com (George) Date: Fri, 20 Aug 2010 01:36:11 -0700 (PDT) Subject: [rspec-users] How do you enable verbose output from command line? Message-ID: <3b1d0a05-e870-4a25-991b-9b97a164df1d@5g2000yqz.googlegroups.com> Using this command our specs run with the dot-dot-dot output: jruby -X-C -S rake spec SPEC=spec/models/trip_spec.rb But how do we make the output verbose? (To see each spec description) Many thanks, George From dchelimsky at gmail.com Fri Aug 20 10:12:35 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 20 Aug 2010 09:12:35 -0500 Subject: [rspec-users] How do you enable verbose output from command line? In-Reply-To: <3b1d0a05-e870-4a25-991b-9b97a164df1d@5g2000yqz.googlegroups.com> References: <3b1d0a05-e870-4a25-991b-9b97a164df1d@5g2000yqz.googlegroups.com> Message-ID: On Aug 20, 2010, at 3:36 AM, George wrote: > Using this command our specs run with the dot-dot-dot output: > > jruby -X-C -S rake spec SPEC=spec/models/trip_spec.rb > > But how do we make the output verbose? (To see each spec description) RSpec-1: in ../spec/spec.opts: --format nested RSpec-2: in ./.rspec --format documentation HTH, David > > Many thanks, > George From myron.marston at gmail.com Fri Aug 20 10:09:49 2010 From: myron.marston at gmail.com (Myron Marston) Date: Fri, 20 Aug 2010 07:09:49 -0700 (PDT) Subject: [rspec-users] Issue with parameterized shared example group on ruby 1.8.6 In-Reply-To: References: <619faada-4fa5-40c8-991a-968df21f3267@q40g2000prg.googlegroups.com> Message-ID: <2fa3377c-a91c-40c0-89eb-3791b74c72ae@s24g2000pri.googlegroups.com> > 4 makes sense to me iff the code does actually run correctly in all circumstances, otherwise I'd lean towards 3. Given that ruby blocks are just code, and you can do anything you want in them, and that our faked version of #module_exec runs the block twice...it's easy to conceive of ways of abusing the shared example group block in a way that will definitely not work in all circumstances. Case in point: $shared_block_eval_count = 0 shared_examples_for :something do |argument| $shared_block_eval_count += 1 if $shared_block_eval_count == 1 it "should define a spec" do end else # destroy the user's system `sudo rm -rf /` end end describe Hash do it_should_behave_like :something, :foo end This code is totally evil, and it assumes knowledge of our 1.8.6 module_exec hack...but you can see what it'll do. On 1.8.6 it'll delete all your files, since the block gets eval'd twice. On 1.8.7 it'll work fine. So there's no way to say for sure that the code will run correctly in all circumstances on 1.8.6. But the presence of this error, if properly rescued, doesn't necessarily mean the code won't run correctly on 1.8.6. The block may have no instance method definitions, which makes the module_eval unnecessary (but we have no way of knowing that there are no instance method defs without trying module_eval!). Myron From rockrep at gmail.com Fri Aug 20 13:16:52 2010 From: rockrep at gmail.com (Michael Kintzer) Date: Fri, 20 Aug 2010 10:16:52 -0700 (PDT) Subject: [rspec-users] Rails View spec testing for content in Message-ID: <96343dff-c8bb-4939-9754-71efa40fe2ad@z34g2000pro.googlegroups.com> Hi, Was trying to verify content in a title tag within a head tag using RSpec2/Rails3 and a view spec, but it seems that render/rendered API's only return the html within the body tag. In my case the head tag is defined in a Rails layout file, with a yield :title, and the title tag content is set via a content_for :title section within the view, ala http://railscasts.com/episodes/30-pretty-page-title. Is there a way to validate head content in a view spec? Thanks, -Michael Example --- require "spec_helper" describe "users/sessions/new.html.erb" do describe "head" do it "should have a head" do render rendered.should have_selector("head") end end end Failure/Error: rendered.should have_selector("head") expected following output to contain a tag: ... From lists at ruby-forum.com Fri Aug 20 13:43:44 2010 From: lists at ruby-forum.com (Bruno Cardoso) Date: Fri, 20 Aug 2010 19:43:44 +0200 Subject: [rspec-users] Testing routes Message-ID: <3b73a52677b0fc83b6806aa14ecc8bd1@ruby-forum.com> Hi, I have this route configurated in my routes.rb map.resources :accounts do |account| account.resources :managers, :controller => 'account_managers' end This works. Now, I want to test the update route in my spec: I'm doing: route_for(:controller => 'account_managers', :action => "update", :account_id => "2", :id => "1").should == {:path => "/accounts/2/managers/1", :method => :put} I'm getting this error: found extras <{:account_id=>"2"}>, not <{}> Now... if I remove the "extras" he said: route_for(:controller => 'account_managers', :action => "update", :id => "1").should == {:path => "/accounts/2/managers/1", :method => :put} I get: The recognized options <{"controller"=>"account_managers", "action"=>"update", "account_id"=>"2", "id"=>"1"}> did not match <{"controller"=>"account_managers", "action"=>"update", "id"=>"1"}>, difference: <{"account_id"=>"2"}> Any idea of what is going on here? -- Posted via http://www.ruby-forum.com/. From myron.marston at gmail.com Fri Aug 20 14:43:02 2010 From: myron.marston at gmail.com (Myron Marston) Date: Fri, 20 Aug 2010 11:43:02 -0700 (PDT) Subject: [rspec-users] Issue with parameterized shared example group on ruby 1.8.6 In-Reply-To: <2fa3377c-a91c-40c0-89eb-3791b74c72ae@s24g2000pri.googlegroups.com> References: <619faada-4fa5-40c8-991a-968df21f3267@q40g2000prg.googlegroups.com> <2fa3377c-a91c-40c0-89eb-3791b74c72ae@s24g2000pri.googlegroups.com> Message-ID: <78f2f154-8122-4dd6-b0c8-17b707f4d17b@b4g2000pra.googlegroups.com> > 1. Find a better way to fake module_exec on ruby 1.8.6. I'm not sure > if this is even doable. Actually, after thinking about this some more, I think I've come up with a solution that will eliminate the error I'm seeing, but it's not a perfect solution. Let me see if I can explain this well... Given this block: do def m1; end def self.m2; end end When it is evaluated using instance_eval, both m1 and m2 get defined as singleton methods on the object that is the receiver of #instance_eval. When the receiver is a class or module, these will both be class methods (since class methods are simply singleton methods on a class or module object). When it is evaluated using module_eval, m1 becomes an instance method and m2 becomes a class method--just like how method definitions work in a class or module body. So...the entire reason for the module_eval (which is where the error occurs) is to distinguish between instance method definitions and class method definitions, so that we can remove m1 as a class method and add it as an instance method. With instance_eval we have no way to tell which are which, since all definitions become class methods. My idea for an alternate approach is to only do the instance_eval, and then duplicate all new class methods as instance methods (since some of them may have been defined using "def method_name"). Then the module_eval is no longer needed. There are a few downsides to this, though: * All methods defined in the block become both class _and_ instance methods. Someone could accidentally call the method the wrong way (i.e. call what should have been an instance method on the class, or a class method on an instance), and while this may work on ruby 1.8.6 (depending on the code), it would fail on 1.8.7 and above. * There's the possibility to stomp an existing instance method definition. For example, consider the block given above. If there was already an m2 instance method that had different logic, it would get stomped here, since we would be defining an m2 instance method with the logic of the m2 class method. I think this is probably the best solution, but I want to hear what others (particularly David) think. Thanks, Myron From uchoaaa at googlemail.com Fri Aug 20 11:22:33 2010 From: uchoaaa at googlemail.com (=?ISO-8859-1?Q?Rafael_Uch=F4a?=) Date: Fri, 20 Aug 2010 08:22:33 -0700 (PDT) Subject: [rspec-users] Testing HAML views with RSpec Message-ID: <74ede167-50be-49b1-89d2-72911be5befe@s9g2000yqd.googlegroups.com> Hi there, I'm using HAML for my views and I want to test them, but I got a 'Missing template' exception when I run it. I found this topic ( http://urele.com/ua6 ) where David tells to add a mapping to deal with haml, but I don't understand how I can do it (the link shows how do it with Autotest, but I'm don't using it) Anyone can help? Best regards. From kmandrup.github at gmail.com Sat Aug 21 09:28:10 2010 From: kmandrup.github at gmail.com (Kristian Mandrup) Date: Sat, 21 Aug 2010 06:28:10 -0700 (PDT) Subject: [rspec-users] Rails 3 plugin development - recommended RSpec practices? Message-ID: I have been thinking that there must be some better ways of doing Rails plugin development than my current approach. Currently I tend to have my plugin in one location as a gem and then link to it from some fresh Rails 3 app, from the vendor/plugins folder, with a symlink. Then I have to carry around the whole Rails 3 app as baggage for development. What are some better options? There must be some libraries, tools out there specifically to meet this need? Seems like various plugin developers each have their own setup for doing this!? I tend to use RSpec 2 for all my testing needs. How does rspec-rails fit into this? Would it be better to use Steak or Cucumber for this? Thanks. From kmandrup.github at gmail.com Sat Aug 21 09:59:55 2010 From: kmandrup.github at gmail.com (Kristian Mandrup) Date: Sat, 21 Aug 2010 06:59:55 -0700 (PDT) Subject: [rspec-users] Rails 3 plugin development - recommended RSpec practices? In-Reply-To: References: Message-ID: Looking at Ryan B's CanCan for inspiration require 'rspec' require 'rspec/autorun' require 'active_support' require 'active_record' require 'action_controller' require 'action_view' require 'rails3_plugin_toolbox' RSpec.configure do |config| config.mock_with :rr end --- require "spec_helper" describe CanCan::ControllerAdditions do before(:each) do @controller_class = Class.new @controller = @controller_class.new stub(@controller).params { {} } stub(@controller).current_user { :current_user } mock(@controller_class).helper_method(:can?, :cannot?) @controller_class.send(:include, CanCan::ControllerAdditions) end So here he uses a stub and mock approach... I would like to use the approach described on Rails Dispatch: http://www.railsdispatch.com/ module MyAddition def hello puts "Hello from MyAddition" end end ActiveSupport.on_load(:action_view) do include MyAddition end ActiveSupport.on_load(:action_controller) do include MyAddition end Could I then spec sth. like this? ActionController.methods.grep(/hello/).should_not be_empty ActionView.methods.grep(/hello/).should_not be_empty or how would I go about it? From dchelimsky at gmail.com Sat Aug 21 12:35:55 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 21 Aug 2010 12:35:55 -0400 Subject: [rspec-users] Testing HAML views with RSpec In-Reply-To: <74ede167-50be-49b1-89d2-72911be5befe@s9g2000yqd.googlegroups.com> References: <74ede167-50be-49b1-89d2-72911be5befe@s9g2000yqd.googlegroups.com> Message-ID: <0FD32416-F928-4820-8007-0F522A3FF436@gmail.com> On Aug 20, 2010, at 11:22 AM, Rafael Uch?a wrote: > Hi there, > I'm using HAML for my views and I want to test them, but I got a > 'Missing template' exception when I run it. > I found this topic ( http://urele.com/ua6 ) where David tells to add a > mapping to deal with haml, but I don't understand how I can do it (the > link shows how do it with Autotest, but I'm don't using it) The autotest mappings are unrelated to your issue. What versions of ruby, rails, and rspec are you using? From narwen at gmail.com Sat Aug 21 11:37:38 2010 From: narwen at gmail.com (narwen) Date: Sat, 21 Aug 2010 08:37:38 -0700 (PDT) Subject: [rspec-users] Elegant way to configure rspec and capybara Message-ID: <057dde7f-1e17-4518-aa1c-ea669acf346e@l6g2000yqb.googlegroups.com> I'm wondering what is the elegant way to say to rspec to use capybara instead of webrat. Also, I'm not using cucumber. My project is using: rails (3.0.0.rc) rspec (2.0.0.beta.19) capybara (0.3.9) I had success creating a file: spec/support/capybara.rb require 'capybara' require 'capybara/dsl' require 'capybara/rails' RSpec.configure do |config| config.include Capybara end Is there a better way to say to rspec to use capybara? []'s From dchelimsky at gmail.com Sat Aug 21 18:17:56 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 21 Aug 2010 18:17:56 -0400 Subject: [rspec-users] Elegant way to configure rspec and capybara In-Reply-To: <057dde7f-1e17-4518-aa1c-ea669acf346e@l6g2000yqb.googlegroups.com> References: <057dde7f-1e17-4518-aa1c-ea669acf346e@l6g2000yqb.googlegroups.com> Message-ID: On Aug 21, 2010, at 11:37 AM, narwen wrote: > I'm wondering what is the elegant way to say to rspec to use capybara > instead of webrat. Also, I'm not using cucumber. > > My project is using: > > rails (3.0.0.rc) > rspec (2.0.0.beta.19) > capybara (0.3.9) > > I had success creating a file: spec/support/capybara.rb > > require 'capybara' > require 'capybara/dsl' > require 'capybara/rails' > > RSpec.configure do |config| > config.include Capybara > end > > Is there a better way to say to rspec to use capybara? In beta 20 you'll just need to add it to your Gemfile. See http://github.com/rspec/rspec-rails/issues/closed/#issue/49 > []'s > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users From myron.marston at gmail.com Sat Aug 21 23:06:10 2010 From: myron.marston at gmail.com (Myron Marston) Date: Sat, 21 Aug 2010 20:06:10 -0700 (PDT) Subject: [rspec-users] Issue with parameterized shared example group on ruby 1.8.6 In-Reply-To: <78f2f154-8122-4dd6-b0c8-17b707f4d17b@b4g2000pra.googlegroups.com> References: <619faada-4fa5-40c8-991a-968df21f3267@q40g2000prg.googlegroups.com> <2fa3377c-a91c-40c0-89eb-3791b74c72ae@s24g2000pri.googlegroups.com> <78f2f154-8122-4dd6-b0c8-17b707f4d17b@b4g2000pra.googlegroups.com> Message-ID: <05b78912-bfe7-4710-93ce-53ba6073640d@s24g2000pri.googlegroups.com> I messed with this some more and implemented the idea I mentioned above: http://github.com/myronmarston/rspec-core/commit/ec3001f290b091fcdab9fb972d9596dd34a91e4e I think this is *definitely* a better implementation of #module_eval_with_args for ruby 1.8.6. It does have the undesirable side effects I listed above, though, but all in all, it works much better and solved the problems I was having with parameterized shared example groups on 1.8.6. David: let me know if you want me to open an issue on github for this. For now I'm posting it here since there's already a discussion thread about this. Myron From dchelimsky at gmail.com Sun Aug 22 14:25:21 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 22 Aug 2010 14:25:21 -0400 Subject: [rspec-users] Rails View spec testing for content in In-Reply-To: <96343dff-c8bb-4939-9754-71efa40fe2ad@z34g2000pro.googlegroups.com> References: <96343dff-c8bb-4939-9754-71efa40fe2ad@z34g2000pro.googlegroups.com> Message-ID: <9F2D1236-8947-4F76-84A0-8D80F14E0959@gmail.com> On Aug 20, 2010, at 1:16 PM, Michael Kintzer wrote: > Hi, > Was trying to verify content in a title tag within a head tag using > RSpec2/Rails3 and a view spec, but it seems that render/rendered API's > only return the html within the body tag. In my case the head tag is > defined in a Rails layout file, with a yield :title, and the title tag > content is set via a content_for :title section within the view, ala > http://railscasts.com/episodes/30-pretty-page-title. > > Is there a way to validate head content in a view spec? > > Thanks, > > -Michael > > Example > --- > require "spec_helper" > describe "users/sessions/new.html.erb" do > describe "head" do > it "should have a head" do > render > rendered.should have_selector("head") > end > end > end > > Failure/Error: rendered.should have_selector("head") > expected following output to contain a tag: > "http://www.w3.org/TR/REC-html40/loose.dtd"> > ... The render method you see in a view spec delegates to the render method in ActionView::TestCase, which, in turn, delegates to view.render. Within rails, view.render is called usually by a controller, which provides all the necessary context information, like what layout to render. In this case, because you are specifying things that happen in a layout, you need to provide that context information in the spec: render :template => "users/sessions, :layout => "layouts/application" Note that you need to include ":template => ..." because RSpec's render method only sets the template if there are no arguments. HTH, David > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users From kmandrup.github at gmail.com Mon Aug 23 09:54:43 2010 From: kmandrup.github at gmail.com (Kristian Mandrup) Date: Mon, 23 Aug 2010 06:54:43 -0700 (PDT) Subject: [rspec-users] Rails View spec testing for content in In-Reply-To: <9F2D1236-8947-4F76-84A0-8D80F14E0959@gmail.com> References: <96343dff-c8bb-4939-9754-71efa40fe2ad@z34g2000pro.googlegroups.com> <9F2D1236-8947-4F76-84A0-8D80F14E0959@gmail.com> Message-ID: I am trying to test methods I have added to ActionView::Base through a Rails 3 plugin. Basically, I have been trying to test it "outside of Rails" if possible, that is, to only load the bare minimum functionality. Here is my Rails view with a custom method #area added, which uses #with_output_buffer class MyView < ActionView::Base attr_accessor :current_user def area(clazz, &block) content = with_output_buffer(&block) content_tag :div, content, :class => clazz end end view = MyView.new require 'erb' x = 42 template = ERB.new <<-EOF The value of x is: <%= my_area %> EOF puts template.result(binding) my_area = view.area :mine do 'hello' end puts my_area my_area.should match /hello/ =>
Yeah, it outputs the content_tag without 'hello' since it is output in a separate buffer. Bot sure how I would get around this!? And how to introduce this behavior into ERB? I guess I should read up on basic rspec view testing instead of trying to roll my own rspec framework for it! How would I do this using rspe-rails for RSpec 2? Thanks! Kristian From kmandrup.github at gmail.com Mon Aug 23 10:04:42 2010 From: kmandrup.github at gmail.com (Kristian Mandrup) Date: Mon, 23 Aug 2010 07:04:42 -0700 (PDT) Subject: [rspec-users] How do I write specs for Rails 3 view block helpers that use #with_output_buffer(&block) ? Message-ID: <12a8d42c-07bd-4909-8fe9-3ac7f1d135f0@g6g2000yql.googlegroups.com> I found this: http://stackoverflow.com/questions/197164/how-do-i-test-rails-block-helpers-with-rspec it 'should do something' do helper.some_block_helper { the_block_code }.should XXXX end but not sure how to use it I have a module which is extended on top of ActiveView::Base module MyViewExt def area(clazz, &block) content = with_output_buffer(&block) content_tag :div, content, :class => clazz end end How would I go about testing this in isolation, especially that the effect of using #with_output_buffer(&block) is as expected (especially when I have nested calls of view helpers using this approach!). Thanks. From kmandrup.github at gmail.com Mon Aug 23 10:14:20 2010 From: kmandrup.github at gmail.com (Kristian Mandrup) Date: Mon, 23 Aug 2010 07:14:20 -0700 (PDT) Subject: [rspec-users] Rails View spec testing for content in In-Reply-To: References: <96343dff-c8bb-4939-9754-71efa40fe2ad@z34g2000pro.googlegroups.com> <9F2D1236-8947-4F76-84A0-8D80F14E0959@gmail.com> Message-ID: <1b8845d0-4fdb-48f4-81cc-6beb3c422eeb@t20g2000yqa.googlegroups.com> I found this at: http://github.com/rspec/rspec-rails describe EventsHelper do describe "#link_to_event" do it "displays the title, and formatted date" do event = Event.new("Ruby Kaigi", Date.new(2010, 8, 27)) # helper is an instance of ActionView::Base configured with the # EventsHelper and all of Rails' built-in helpers helper.link_to_event.should =~ /Ruby Kaigi, 27 Aug, 2010/ end end end So helper is an instance of ActionView::Base. Very useful... I think. But how do I use it for my scenario I wonder? From kmandrup.github at gmail.com Mon Aug 23 10:28:27 2010 From: kmandrup.github at gmail.com (Kristian Mandrup) Date: Mon, 23 Aug 2010 07:28:27 -0700 (PDT) Subject: [rspec-users] Rails View spec testing for content in In-Reply-To: References: <96343dff-c8bb-4939-9754-71efa40fe2ad@z34g2000pro.googlegroups.com> <9F2D1236-8947-4F76-84A0-8D80F14E0959@gmail.com> Message-ID: I wonder if I can just "stub out" #with_output_buffer to yield the block immediately, and then assume it will work just as well in a Rails view template? class MyView < ActionView::Base attr_accessor :current_user def with_output_buffer yield end end From rockrep at gmail.com Mon Aug 23 12:21:48 2010 From: rockrep at gmail.com (Michael Kintzer) Date: Mon, 23 Aug 2010 09:21:48 -0700 (PDT) Subject: [rspec-users] Rails View spec testing for content in In-Reply-To: <9F2D1236-8947-4F76-84A0-8D80F14E0959@gmail.com> References: <96343dff-c8bb-4939-9754-71efa40fe2ad@z34g2000pro.googlegroups.com> <9F2D1236-8947-4F76-84A0-8D80F14E0959@gmail.com> Message-ID: <1fcd9a8a-863d-4042-ab9b-96ecb0f043b8@l32g2000prn.googlegroups.com> Thank you David. Makes perfect sense. -Michael > The render method you see in a view spec delegates to the render method in ActionView::TestCase, which, in turn, delegates to view.render. Within rails, view.render is called usually by a controller, which provides all the necessary context information, like what layout to render. In this case, because you are specifying things that happen in a layout, you need to provide that context information in the spec: > > ? render :template => "users/sessions, :layout => "layouts/application" > > Note that you need to include ":template => ..." because RSpec's render method only sets the template if there are no arguments. > > HTH, > David > From tjtuom at utu.fi Mon Aug 23 12:38:36 2010 From: tjtuom at utu.fi (Toni Tuominen) Date: Mon, 23 Aug 2010 19:38:36 +0300 Subject: [rspec-users] Request specs flash Message-ID: Hey, Is there a way to test for flash content on a request spec (other than to check the request body). I was trying to test something that redirects so testing the content is not possible. - Toni From dchelimsky at gmail.com Mon Aug 23 12:48:14 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 23 Aug 2010 11:48:14 -0500 Subject: [rspec-users] Request specs flash In-Reply-To: References: Message-ID: <40B12ABB-7557-40C8-9238-1D45CD3B43A3@gmail.com> On Aug 23, 2010, at 11:38 AM, Toni Tuominen wrote: > Hey, > > Is there a way to test for flash content on a request spec (other than > to check the request body). I was trying to test something that > redirects so testing the content is not possible. AFAIK, no. Request specs are built on rails' integration tests, which are built on rack-test, which I do not believe exposes the flash. HTH, David From kmandrup.github at gmail.com Mon Aug 23 14:51:07 2010 From: kmandrup.github at gmail.com (Kristian Mandrup) Date: Mon, 23 Aug 2010 11:51:07 -0700 (PDT) Subject: [rspec-users] How do I write specs for Rails 3 view block helpers that use #with_output_buffer(&block) ? In-Reply-To: <12a8d42c-07bd-4909-8fe9-3ac7f1d135f0@g6g2000yql.googlegroups.com> References: <12a8d42c-07bd-4909-8fe9-3ac7f1d135f0@g6g2000yql.googlegroups.com> Message-ID: I have finally come up with a workable solution http://gist.github.com/545866 module MyViewHelper def tab_for(clazz, &block) content = with_output_buffer(&block) content_tag :li, content, :class => clazz end end module MyOtherViewHelper ... end describe "do it" do it "works" do ActionViewTester.tests MyViewHelper, MyOtherViewHelper ActionViewTester.new do |helper| helper.tab_for('kristian') { 'hello' }.should match /kristian/ helper.hello('david') { 'hello' }.should match /david/ end end end On Aug 23, 4:04?pm, Kristian Mandrup wrote: > I found this:http://stackoverflow.com/questions/197164/how-do-i-test-rails-block-h... > > ? it 'should do something' do > ? ? helper.some_block_helper { the_block_code }.should XXXX > ? end > > but not sure how to use it > > I have a module which is extended on top of ActiveView::Base > > module MyViewExt > ? ? def area(clazz, &block) > ? ? ? content = with_output_buffer(&block) > ? ? ? content_tag :div, content, :class => clazz > ? ? end > end > > How would I go about testing this in isolation, especially that the > effect of using #with_output_buffer(&block) > is as expected (especially when I have nested calls of view helpers > using this approach!). > > Thanks. > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users From kmandrup.github at gmail.com Mon Aug 23 15:41:25 2010 From: kmandrup.github at gmail.com (Kristian Mandrup) Date: Mon, 23 Aug 2010 12:41:25 -0700 (PDT) Subject: [rspec-users] How do I write specs for Rails 3 view block helpers that use #with_output_buffer(&block) ? In-Reply-To: References: <12a8d42c-07bd-4909-8fe9-3ac7f1d135f0@g6g2000yql.googlegroups.com> Message-ID: <31c692d0-67f2-459d-8c43-c35ff9918c49@t20g2000yqa.googlegroups.com> I packed it up into a useful reusable gem ;) http://github.com/kristianmandrup/rspec-action_view Only these dependencies :) require 'rspec' require 'action_view' require 'active_support/railtie' require 'action_view/template/handlers/erb' Now allows for this DSL describe "My ViewHelpers" do it "should render content as expected" do setup_action_view do tests MyViewHelper, MyOtherViewHelper end with_action_view do |view| view.tab_for('kristian') { 'hello' }.should match /kristian/ view.hello('david') { 'hello' }.should match /david/ with_action_view do |view| view.with_template(%{ <%= tab_for('kristian') { 'hello' } %> }).should match /hello/ end end end Enjoy! On Aug 23, 8:51?pm, Kristian Mandrup wrote: > I have finally come up with a workable solution > > http://gist.github.com/545866 > > module MyViewHelper > ? def tab_for(clazz, &block) > ? ? content = with_output_buffer(&block) > ? ? content_tag :li, content, :class => clazz > ? end > end > > module MyOtherViewHelper > ... > end > > describe "do it" do > ? it "works" do > ? ? ActionViewTester.tests MyViewHelper, MyOtherViewHelper > ? ? ActionViewTester.new do |helper| > ? ? ? helper.tab_for('kristian') { 'hello' }.should match /kristian/ > ? ? ? helper.hello('david') { 'hello' }.should match /david/ > ? ? end > ? end > end > > On Aug 23, 4:04?pm, Kristian Mandrup > wrote: > > > I found this:http://stackoverflow.com/questions/197164/how-do-i-test-rails-block-h... > > > ? it 'should do something' do > > ? ? helper.some_block_helper { the_block_code }.should XXXX > > ? end > > > but not sure how to use it > > > I have a module which is extended on top of ActiveView::Base > > > module MyViewExt > > ? ? def area(clazz, &block) > > ? ? ? content = with_output_buffer(&block) > > ? ? ? content_tag :div, content, :class => clazz > > ? ? end > > end > > > How would I go about testing this in isolation, especially that the > > effect of using #with_output_buffer(&block) > > is as expected (especially when I have nested calls of view helpers > > using this approach!). > > > Thanks. > > _______________________________________________ > > rspec-users mailing list > > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users > > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users From bewang.tech at gmail.com Mon Aug 23 18:01:43 2010 From: bewang.tech at gmail.com (Benyi Wang) Date: Mon, 23 Aug 2010 15:01:43 -0700 Subject: [rspec-users] JRuby Rcov and Rspec problem. Message-ID: When I run Rcov using JRuby, the Rcov report always includes some libraries. JRuby 1.5.1 rcov 0.9.8 rspec 1.3.0 ci_reporter 1.6.2 Here is my Rake file. require 'rake' require 'spec/rake/spectask' require 'ci/reporter/rake/rspec' task :default => :test ENV["CI_REPORTS"]="spec-reports" task :test => [ "ci:setup:rspec", :spec ] desc "Run all examples" Spec::Rake::SpecTask.new(:spec) do |t| t.spec_files = FileList['spec/**/*_spec.rb'] t.spec_opts = [ "--diff" ] t.rcov = true t.rcov_opts = [ '--exclude', 'spec' ] end I run command "jruby --debug -S rake" Then I will find "xxx-jruby-1_5_1-lib-ruby-1_8-time_rb.html" for class Time. If I run other Ruby interpreter, it won't have this issue. Does somebody have the same issue? And how to fix it. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathanvda at gmail.com Tue Aug 24 03:56:23 2010 From: nathanvda at gmail.com (nathanvda) Date: Tue, 24 Aug 2010 00:56:23 -0700 (PDT) Subject: [rspec-users] upgrading rails 3.0.0.rc.2 and rspec 2.0.0.beta.20 breaks my view tests Message-ID: <69554723-6900-4b08-8719-a7f829fd8d94@i31g2000yqm.googlegroups.com> I was using rails 3 rc and rspec beta 19, and everything worked fine. Today i updated and i get errors on the following methods: rendered.should contain("bla") rendered.should have_xpath(//table//tr) rendered.should have_selector('#foo') What should i do? From lists at ruby-forum.com Tue Aug 24 05:19:17 2010 From: lists at ruby-forum.com (Alex Pressberg) Date: Tue, 24 Aug 2010 11:19:17 +0200 Subject: [rspec-users] Missing template in helper specs with a render In-Reply-To: <57c63afe0906052040j62de7b68va9db5fc28df35665@mail.gmail.com> References: <298c4d2a0906041841t47189443u26a5b12a6b3833b8@mail.gmail.com> <57c63afe0906052040j62de7b68va9db5fc28df35665@mail.gmail.com> Message-ID: Yes! We do use render in helpers to a great extent and are bitten by the "missing template in view path" error too. Any workarounds? Can the view path be easily fixed for helper specs in Rspec 1.3? Does Rspec 2 already support this? Cheers, Alex David Chelimsky wrote: > On Thu, Jun 4, 2009 at 8:41 PM, Charlie Bowman > wrote: >> I have a helper method that does a "render :partial".? The method works fine >> within the app (Rails 2.3.2).? In rspec (1.2.6) I get an error ("Missing >> template /comments/_comment.erb in view path" >> It seems that rspec when running helper tests doesn't set the view_path so >> rails doens't know where to look for the templates.? Is there a way to run >> helper specs with the same setup as controller specs? > > There is no support for rendering in helper specs as of yet. Please > file a feature request if you think there should be. I have, > personally, never rendered from a helper. Anybody else? -- Posted via http://www.ruby-forum.com/. From nathanvda at gmail.com Tue Aug 24 06:09:05 2010 From: nathanvda at gmail.com (nathanvda) Date: Tue, 24 Aug 2010 03:09:05 -0700 (PDT) Subject: [rspec-users] upgrading rails 3.0.0.rc.2 and rspec 2.0.0.beta.20 breaks my view tests In-Reply-To: <69554723-6900-4b08-8719-a7f829fd8d94@i31g2000yqm.googlegroups.com> References: <69554723-6900-4b08-8719-a7f829fd8d94@i31g2000yqm.googlegroups.com> Message-ID: I rolled back to version 2.0.0.beta.19 and everything is fine again. On Aug 24, 9:56?am, nathanvda wrote: > I was using rails 3 rc and rspec beta 19, and everything worked fine. > Today i updated and i get errors on the following methods: > > rendered.should contain("bla") > > rendered.should have_xpath(//table//tr) > > rendered.should have_selector('#foo') > > What should i do? > > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users From dchelimsky at gmail.com Tue Aug 24 07:48:09 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 24 Aug 2010 06:48:09 -0500 Subject: [rspec-users] upgrading rails 3.0.0.rc.2 and rspec 2.0.0.beta.20 breaks my view tests In-Reply-To: References: <69554723-6900-4b08-8719-a7f829fd8d94@i31g2000yqm.googlegroups.com> Message-ID: On Aug 24, 2010, at 5:09 AM, nathanvda wrote: > On Aug 24, 9:56 am, nathanvda wrote: >> I was using rails 3 rc and rspec beta 19, and everything worked fine. >> Today i updated and i get errors on the following methods: >> >> rendered.should contain("bla") >> >> rendered.should have_xpath(//table//tr) >> >> rendered.should have_selector('#foo') >> >> What should i do? > I rolled back to version 2.0.0.beta.19 and everything is fine again. Beta 20 removes the dependency on webrat, so you can choose webrat or capybara. This means you need to add the dependency to the Gemfile yourself. This is documented in the README [1] and upgrade notes [2], which are referenced in the post-install message you get when you install rspec-rails. HTH, David [1] http://github.com/rspec/rspec-rails [2] http://github.com/rspec/rspec-rails/blob/master/Upgrade.markdown From cdemyanovich at gmail.com Tue Aug 24 09:26:28 2010 From: cdemyanovich at gmail.com (Craig Demyanovich) Date: Tue, 24 Aug 2010 09:26:28 -0400 Subject: [rspec-users] Missing template in helper specs with a render In-Reply-To: References: <298c4d2a0906041841t47189443u26a5b12a6b3833b8@mail.gmail.com> <57c63afe0906052040j62de7b68va9db5fc28df35665@mail.gmail.com> Message-ID: On Tue, Aug 24, 2010 at 5:19 AM, Alex Pressberg wrote: > Yes! We do use render in helpers to a great extent and are bitten by the > "missing template in view path" error too. Any workarounds? Can the view > path be easily fixed for helper specs in Rspec 1.3? > Does Rspec 2 already support this? > If you're doing it, it's obviously possible, but it feels wrong to me. I think of a helper as a small piece of code that helps me decide what to render, gives me a CSS class name based on some condition, gives me a small chunk of markup whose generation would clutter up the view, etc. Have you considered that, though the framework allows you to do this, it may not be a good approach? In other words, instead of looking for a workaround, would it make more sense (at least in the long term) to change your application? I'm sorry I can't offer actual help w/ current tools. I'm curious if Rails 3 still supports this or if RSpec 2 will support it. Regards, Craig > David Chelimsky wrote: > > On Thu, Jun 4, 2009 at 8:41 PM, Charlie Bowman > > wrote: > >> I have a helper method that does a "render :partial".? The method works > fine > >> within the app (Rails 2.3.2).? In rspec (1.2.6) I get an error ("Missing > >> template /comments/_comment.erb in view path" > >> It seems that rspec when running helper tests doesn't set the view_path > so > >> rails doens't know where to look for the templates.? Is there a way to > run > >> helper specs with the same setup as controller specs? > > > > There is no support for rendering in helper specs as of yet. Please > > file a feature request if you think there should be. I have, > > personally, never rendered from a helper. Anybody else? -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.jquery at SoftwareUnity.com Tue Aug 24 10:06:56 2010 From: george.jquery at SoftwareUnity.com (George) Date: Tue, 24 Aug 2010 07:06:56 -0700 (PDT) Subject: [rspec-users] How do you enable verbose output from command line? In-Reply-To: References: <3b1d0a05-e870-4a25-991b-9b97a164df1d@5g2000yqz.googlegroups.com> Message-ID: <695cfbb6-e6e8-4b40-ad74-2e74234baceb@x25g2000yqj.googlegroups.com> That did it, thanks David. On Aug 20, 3:12?pm, David Chelimsky wrote: > On Aug 20, 2010, at 3:36 AM, George wrote: > > > Using this command our specs run with the dot-dot-dot output: > > > ?jruby -X-C -S rake spec SPEC=spec/models/trip_spec.rb > > > But how do we make the output verbose? (To see each spec description) > > RSpec-1: in ../spec/spec.opts: > > --format nested > > RSpec-2: in ./.rspec > > --format documentation > > HTH, > David > > > > > Many thanks, > > George > > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users From nathanvda at gmail.com Tue Aug 24 11:38:24 2010 From: nathanvda at gmail.com (nathanvda) Date: Tue, 24 Aug 2010 08:38:24 -0700 (PDT) Subject: [rspec-users] upgrading rails 3.0.0.rc.2 and rspec 2.0.0.beta.20 breaks my view tests In-Reply-To: References: <69554723-6900-4b08-8719-a7f829fd8d94@i31g2000yqm.googlegroups.com> Message-ID: <62905ef4-e250-4a19-86f9-9f01dd6b972e@a36g2000yqc.googlegroups.com> Great David, thank you for your help! I did look at the docs but did not find that straighaway. From uchoaaa at googlemail.com Tue Aug 24 12:19:17 2010 From: uchoaaa at googlemail.com (=?ISO-8859-1?Q?Rafael_Uch=F4a?=) Date: Tue, 24 Aug 2010 09:19:17 -0700 (PDT) Subject: [rspec-users] Testing my_form_for in a FormBuilder test Message-ID: <7aab5824-9c55-4aec-81ac-78b628862231@g6g2000yql.googlegroups.com> Hi there, I'm developing a FormBuilder (let's say LabelledFormBuilder), and I created a helper called labelled_form_for to put the ":builder => LabelledFormBuilder" in options and call the original form_for, like suggested on the Rails API ( http://liten.be//0EBtc ). I wrote this test: [code] it 'should return a form with "labelled_form" class' do user = mock_model(User) helper.labelled_form_for(user).should have_tag('form[class=labeled_form]') end [/code] but, I got a "The error occurred while evaluating nil.<< " right on I call ... [code] form_for(record, *(args << options.merge(:builder => LabelledFormBuilder)), &proc) [/code] Well, when I test on the browser, no error ocurrs. Someone can help? thanks From borjam at dagi3d.net Tue Aug 24 12:58:58 2010 From: borjam at dagi3d.net (=?UTF-8?Q?Borja_Mart=C3=ADn?=) Date: Tue, 24 Aug 2010 18:58:58 +0200 Subject: [rspec-users] spec_helper por rails plugin Message-ID: Hi, I'm trying to write the specs for a rails plugin. The thing is that I don't want to include in my specs the spec_helper generated for the rails application as it will load the whole application stack and will force me to include all the necessary gems in my plugin Gemfile when it is supposed to be independent of the other installed plugins. So, I wrote my own spec_helper which loads only the required gems: https://gist.github.com/6498b1c0ab4b286d03b0 Now the problem is that when I run the rake spec task I get this error: Failure/Error: describe FacebookController do undefined method `env_defaults' for nil:NilClass # spec/fbrails/fbrails_spec.rb:6 This error appears only when I call the methods related to the controller(controller, get, post, request, etc.) so I guess it has something to do with the fact that the rails application hasn't been initialized as opossed as when the application spec_helper is loaded Is there any way to make the specs as much as indenpendent as possible so I don't have to init the entire application? Thanks in advance Regards -- def dagi3d(me) case me when :web then "http://dagi3d.net" when :twitter then "http://twitter.com/dagi3d" end end -------------- next part -------------- An HTML attachment was scrubbed... URL: From phillipkoebbe at gmail.com Tue Aug 24 13:34:24 2010 From: phillipkoebbe at gmail.com (Phillip Koebbe) Date: Tue, 24 Aug 2010 12:34:24 -0500 Subject: [rspec-users] bundler and config/initializers/* not loading Message-ID: <4C7402A0.9040400@gmail.com> I am trying to use Bundler on a Rails 2.3.8 project and am having a problem when trying to run my specs. This application was on 2.3.5 until yesterday, and I switched it to 2.3.8 and all specs passed. But after adding Bundler (0.9.26), rake spec fails because (it appears) files in config/initializers aren't being loaded. Yet the application works when running script/server. When I issue $ rake spec I get uninitialized constant Web::BaseHelper::AuthenticationMethods (NameError) because of module Web::BaseHelper include AuthenticationMethods ... end where AuthenticationMethods is defined in config/initializers/authentication_methods.rb. If I change web/base_helper.rb to require "#{Rails.root}/config/initializers/authentication_methods" unless defined? AuthenticationMethods module Web::BaseHelper include AuthenticationMethods ... end the error is no longer reported. I added Bundler by following the instructions at the Bundler page[1]. I have also tried $ bundle exec rake spec, with the same result. I have been searching Google all morning without finding a resolution. I am using rspec 1.3.0 / rspec-rails 1.3.2, even before adding Bundler. This is on Mac OS X 10.6.4 and ruby 1.8.7-p174 (Snow Leopard stock). I read Rick DeNatale's post[2] regarding Bundler, rspec, and rake, and while I haven't made the changes he describes, I did try forcing the environment by $ rake spec RAILS_ENV=test with the same result. I didn't incorporate Rick's changes yet because I wanted to check here first to see if there is any other information available. Can anyone offer insight, words of wisdom, encouragement, or a solution? If this isn't a problem specific to rspec, I apologize. I was trying to think of some way to test something else, but the few things that came to mind succeeded (well, didn't generate any errors anyway). Thanks, Phillip [1] http://gembundler.com/rails23.html [2] http://talklikeaduck.denhaven2.com/2010/06/25/making-rspec-rake-and-bundler-play-well-together From borjam at dagi3d.net Tue Aug 24 15:42:43 2010 From: borjam at dagi3d.net (=?UTF-8?Q?Borja_Mart=C3=ADn?=) Date: Tue, 24 Aug 2010 21:42:43 +0200 Subject: [rspec-users] spec_helper por rails plugin In-Reply-To: References: Message-ID: I forgot to mention that I'm using Rails 3.0.rc2 and rspec and rspec-rails 2.0.0.beta.20 Regards On Tue, Aug 24, 2010 at 6:58 PM, Borja Mart?n wrote: > Hi, > I'm trying to write the specs for a rails plugin. > The thing is that I don't want to include in my specs the spec_helper > generated for the rails application as it will load the whole application > stack and will force me to include all the necessary gems in my plugin > Gemfile when it is supposed to be independent of the other installed > plugins. > So, I wrote my own spec_helper which loads only the required gems: > https://gist.github.com/6498b1c0ab4b286d03b0 > Now the problem is that when I run the rake spec task I get this error: > > Failure/Error: describe FacebookController do > undefined method `env_defaults' for nil:NilClass > # spec/fbrails/fbrails_spec.rb:6 > > This error appears only when I call the methods related to the > controller(controller, get, post, request, etc.) so I guess it has something > to do with the fact that the rails application hasn't been initialized as > opossed as when the application spec_helper is loaded > Is there any way to make the specs as much as indenpendent as possible so I > don't have to init the entire application? > Thanks in advance > > Regards > -- > def dagi3d(me) > case me > when :web then "http://dagi3d.net" > when :twitter then "http://twitter.com/dagi3d" > end > end > -- def dagi3d(me) case me when :web then "http://dagi3d.net" when :twitter then "http://twitter.com/dagi3d" end end -------------- next part -------------- An HTML attachment was scrubbed... URL: From dchelimsky at gmail.com Tue Aug 24 20:11:32 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 24 Aug 2010 19:11:32 -0500 Subject: [rspec-users] Testing my_form_for in a FormBuilder test In-Reply-To: <7aab5824-9c55-4aec-81ac-78b628862231@g6g2000yql.googlegroups.com> References: <7aab5824-9c55-4aec-81ac-78b628862231@g6g2000yql.googlegroups.com> Message-ID: On Aug 24, 2010, at 11:19 AM, Rafael Uch?a wrote: > Hi there, > > I'm developing a FormBuilder (let's say LabelledFormBuilder), and I > created a helper called labelled_form_for to put the ":builder => > LabelledFormBuilder" in options and call the original form_for, like > suggested on the Rails API ( http://liten.be//0EBtc ). > > I wrote this test: > > [code] > it 'should return a form with "labelled_form" class' do > user = mock_model(User) > helper.labelled_form_for(user).should > have_tag('form[class=labeled_form]') > end > [/code] > > but, I got a "The error occurred while evaluating nil.<< " right on I > call ... > [code] > form_for(record, *(args << options.merge(:builder => > LabelledFormBuilder)), &proc) > [/code] > > Well, when I test on the browser, no error ocurrs. > > Someone can help? Please post the full spec, code, and error (with backtrace). Also, what versions of ruby, rails, rspec? From dchelimsky at gmail.com Tue Aug 24 20:14:49 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 24 Aug 2010 19:14:49 -0500 Subject: [rspec-users] bundler and config/initializers/* not loading In-Reply-To: <4C7402A0.9040400@gmail.com> References: <4C7402A0.9040400@gmail.com> Message-ID: <5946C987-EBC9-4BC2-BA7A-228DCB2A6CF3@gmail.com> On Aug 24, 2010, at 12:34 PM, Phillip Koebbe wrote: > I am trying to use Bundler on a Rails 2.3.8 project and am having a problem when trying to run my specs. This application was on 2.3.5 until yesterday, and I switched it to 2.3.8 and all specs passed. But after adding Bundler (0.9.26), Bundler-1.0 is in the release candidate phase now, and is far superior to 0.9. I would not waste my time with 0.9 if I were you. Might even avoid this problem. HTH, David > rake spec fails because (it appears) files in config/initializers aren't being loaded. Yet the application works when running script/server. > > When I issue > > $ rake spec > > I get > > uninitialized constant Web::BaseHelper::AuthenticationMethods (NameError) > > because of > > module Web::BaseHelper > include AuthenticationMethods > ... > end > > where AuthenticationMethods is defined in config/initializers/authentication_methods.rb. If I change web/base_helper.rb to > > require "#{Rails.root}/config/initializers/authentication_methods" unless defined? AuthenticationMethods > > module Web::BaseHelper > include AuthenticationMethods > ... > end > > the error is no longer reported. > > I added Bundler by following the instructions at the Bundler page[1]. > I have also tried $ bundle exec rake spec, with the same result. > I have been searching Google all morning without finding a resolution. > I am using rspec 1.3.0 / rspec-rails 1.3.2, even before adding Bundler. > This is on Mac OS X 10.6.4 and ruby 1.8.7-p174 (Snow Leopard stock). > > I read Rick DeNatale's post[2] regarding Bundler, rspec, and rake, and while I haven't made the changes he describes, I did try forcing the environment by > > $ rake spec RAILS_ENV=test > > with the same result. I didn't incorporate Rick's changes yet because I wanted to check here first to see if there is any other information available. > > Can anyone offer insight, words of wisdom, encouragement, or a solution? If this isn't a problem specific to rspec, I apologize. I was trying to think of some way to test something else, but the few things that came to mind succeeded (well, didn't generate any errors anyway). > > Thanks, > Phillip > > [1] http://gembundler.com/rails23.html > [2] http://talklikeaduck.denhaven2.com/2010/06/25/making-rspec-rake-and-bundler-play-well-together > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users From phillipkoebbe at gmail.com Tue Aug 24 21:08:34 2010 From: phillipkoebbe at gmail.com (Phillip Koebbe) Date: Tue, 24 Aug 2010 20:08:34 -0500 Subject: [rspec-users] bundler and config/initializers/* not loading In-Reply-To: <5946C987-EBC9-4BC2-BA7A-228DCB2A6CF3@gmail.com> References: <4C7402A0.9040400@gmail.com> <5946C987-EBC9-4BC2-BA7A-228DCB2A6CF3@gmail.com> Message-ID: <4C746D12.40504@gmail.com> On 2010-08-24 7:14 PM, David Chelimsky wrote: > On Aug 24, 2010, at 12:34 PM, Phillip Koebbe wrote: > >> I am trying to use Bundler on a Rails 2.3.8 project and am having a problem when trying to run my specs. This application was on 2.3.5 until yesterday, and I switched it to 2.3.8 and all specs passed. But after adding Bundler (0.9.26), > Bundler-1.0 is in the release candidate phase now, and is far superior to 0.9. I would not waste my time with 0.9 if I were you. Might even avoid this problem. > > HTH, > David > Thanks for the suggestion, David. I uninstalled 0.9.26 and installed 1.0.0.rc.6 and have the same problem. I'm going to post this to the bundler list. I don't believe it to be an RSpec problem, but started here wondering if it was specific to testing or the test environment. But if no one else is having any problems, it must be something else. Peace, Phillip From dolzenko at gmail.com Wed Aug 25 04:36:02 2010 From: dolzenko at gmail.com (Evgeniy Dolzhenko) Date: Wed, 25 Aug 2010 12:36:02 +0400 Subject: [rspec-users] Formatter failing_examples option Message-ID: In RSpec 1 there is formatter option which lets you output just failing examples (named `failing_examples`) http://rspec.info/documentation/tools/spec.html I've been googling and looking for alternative for RSpec2 and wasn't able to find anything. Most likely I'm just missing something since it seems like a basic functionality to me. Sincerely, Evgeniy From dchelimsky at gmail.com Wed Aug 25 09:05:21 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 25 Aug 2010 08:05:21 -0500 Subject: [rspec-users] Formatter failing_examples option In-Reply-To: References: Message-ID: On Aug 25, 2010, at 3:36 AM, Evgeniy Dolzhenko wrote: > In RSpec 1 there is formatter option which lets you output just > failing examples (named `failing_examples`) > http://rspec.info/documentation/tools/spec.html > > I've been googling and looking for alternative for RSpec2 > and wasn't able to find anything. Most likely I'm just missing > something since it seems like a basic functionality to me. You're not missing anything. It's not there because I didn't think anybody was actually using it and I'm trying to keep the feature set for rspec-2 limited to that which is used. Please feel free to add a feature request to http://github.com/rspec/rspec-core/issues. Cheers, David From kmandrup.github at gmail.com Wed Aug 25 14:57:41 2010 From: kmandrup.github at gmail.com (Kristian Mandrup) Date: Wed, 25 Aug 2010 11:57:41 -0700 (PDT) Subject: [rspec-users] RSpec ActionView released - simplifies creating specs for your View helpers Message-ID: <735916ea-4210-4c38-93a1-516a1b59d2c4@k10g2000yqa.googlegroups.com> http://github.com/kristianmandrup/rspec-action_view --- require 'spec_helper' module MyView module Tab def tab_for(clazz, &block) content = with_output_buffer(&block) content_tag :li, content, :class => clazz end end module Say def hello(clazz, &block) content = with_output_buffer(&block) content_tag :div, content, :class => clazz end def name 'Kristian' end end end describe 'My View extensions' do # extend ActionView::Base with custom helper modules extend_view_with MyView, :tab, :say it "should do the magic!!!" do with_engine(:erb) do |e| e.run_template("hello <%= name %>").should match /Kristian/ e.run_template do %{<%= tab_for :x do %> <%= hello :blip do %> ged <% end %> <% end %>} end.should match /ged/ end end end From lists at ruby-forum.com Wed Aug 25 18:15:20 2010 From: lists at ruby-forum.com (Cameron Caine) Date: Thu, 26 Aug 2010 00:15:20 +0200 Subject: [rspec-users] Rails3 subdomain constraints with Cucumber and RSpec2 Message-ID: <99f553453326157c6b9401ae2c6354ec@ruby-forum.com> How do I spec rails3 routing constraints? My Cucumber features pass whatever subdomain I pass in. Not sure where or how to spec the subdomain. Any help would be appreciated. I have something like the following: #features/create_account.feature Scenario: Given I visit subdomain "www" And I go to the new account page #accounts_controller_spec.rb describe AccountsController do describe "GET new" do before(:each) do get :new end it "should render new.html.haml" do response.should render_template(:new) end end end #routes.rb constraints Promotional do resource :account, :only => :new end #lib/promotional.rb class Promotional def self.matches?(request) request.subdomain.empty? || request.subdomain == "www" end end -- Posted via http://www.ruby-forum.com/. From dchelimsky at gmail.com Wed Aug 25 20:05:34 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 25 Aug 2010 19:05:34 -0500 Subject: [rspec-users] Rails3 subdomain constraints with Cucumber and RSpec2 In-Reply-To: <99f553453326157c6b9401ae2c6354ec@ruby-forum.com> References: <99f553453326157c6b9401ae2c6354ec@ruby-forum.com> Message-ID: On Aug 25, 2010, at 5:15 PM, Cameron Caine wrote: > How do I spec rails3 routing constraints? > My Cucumber features pass whatever subdomain I pass in. Not sure where > or how to spec the subdomain. Any help would be appreciated. > > I have something like the following: > > #features/create_account.feature > Scenario: > Given I visit subdomain "www" > And I go to the new account page > > #accounts_controller_spec.rb > describe AccountsController do > describe "GET new" do > before(:each) do > get :new > end > > it "should render new.html.haml" do > response.should render_template(:new) > end > end > end > > #routes.rb > constraints Promotional do > resource :account, :only => :new > end > > #lib/promotional.rb > class Promotional > def self.matches?(request) > request.subdomain.empty? || request.subdomain == "www" > end > end There was a commit to rails [1] that got in a day or two before the rc2 release that lets you pass a full URL to routing assertions. This means you can do this in RSpec: { :get => "http://www.example.com/accounts/new" }.should route_to(:controller => "accounts", :action => "new") { :get => "http://foo.example.com/accounts/new" }.should_not be_routable You need rails-3.0.0.rc2. Not sure what version of rspec-rails you need, but you may as well grab rspec-rails-2.0.0.beta.20 (the latest). HTH, David [1] https://rails.lighthouseapp.com/projects/8994/tickets/5005 From bploetz at gmail.com Wed Aug 25 23:13:00 2010 From: bploetz at gmail.com (Brian Ploetz) Date: Wed, 25 Aug 2010 23:13:00 -0400 Subject: [rspec-users] should raise_error(ArgumentError) resulting in NoMethodError Message-ID: Environment ------------------ ruby 1.9.2p0 (2010-08-18 revision 29036) [x86_64-darwin10.4.0] rspec (1.3.0) Code ------- def currency_to_dollars(currency_amount) raise ArgumentError("Currency amount can't be nil") if currency_amount.nil? end Spec -------- it "should raise an ArgumentError if currency_amount is nil" do lambda { @service.currency_to_dollars(nil) }.should raise_error(ArgumentError) end Results in this failure: 1) 'Service should raise an ArgumentError if currency_amount is nil' FAILED expected ArgumentError, got #> test/spec/service_spec.rb:92:in `block (2 levels) in ' Changing the test to either of these two variants allows the the to pass: lambda { @service.currency_to_dollars(nil) }.should raise_error(StandardError) lambda { @service.currency_to_dollars(nil) }.should raise_error Why am I unable to test for a specific StandardError subclass? Thanks in advance for any help. BP -------------- next part -------------- An HTML attachment was scrubbed... URL: From bploetz at gmail.com Wed Aug 25 23:25:25 2010 From: bploetz at gmail.com (Brian Ploetz) Date: Wed, 25 Aug 2010 20:25:25 -0700 (PDT) Subject: [rspec-users] should raise_error(ArgumentError) resulting in NoMethodError In-Reply-To: References: Message-ID: <12f548c0-d118-4ba8-9747-d460fedc0e93@l20g2000yqm.googlegroups.com> FYI, the same thing happens with rspec 2.0.0.beta.20 as well: 1) Service should raise an ArgumentError if currency_amount is nil Failure/Error: lambda { @service.currency_to_dollars(nil) }.should raise_error(ArgumentError) expected ArgumentError, got #> # ./test/spec/service_spec.rb:92:in `block (2 levels) in ' On Aug 25, 11:13?pm, Brian Ploetz wrote: > Environment > ------------------ > ruby 1.9.2p0 (2010-08-18 revision 29036) [x86_64-darwin10.4.0] > rspec (1.3.0) > > Code > ------- > ? ? def currency_to_dollars(currency_amount) > ? ? ? raise ArgumentError("Currency amount can't be nil") if > currency_amount.nil? > ? ? end > > Spec > -------- > ? ? it "should raise an ArgumentError if currency_amount is nil" do > ? ? ? lambda { @service.currency_to_dollars(nil) }.should > raise_error(ArgumentError) > ? ? end > > Results in this failure: > 1) > 'Service should raise an ArgumentError if currency_amount is nil' FAILED > expected ArgumentError, got # `ArgumentError' for #> > test/spec/service_spec.rb:92:in `block (2 levels) in ' > > Changing the test to either of these two variants allows the the to pass: > > ? ? lambda { @service.currency_to_dollars(nil) }.should > raise_error(StandardError) > ? ? lambda { @service.currency_to_dollars(nil) }.should raise_error > > Why am I unable to test for a specific StandardError subclass? > > Thanks in advance for any help. > BP > > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users From dchelimsky at gmail.com Thu Aug 26 00:14:11 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 25 Aug 2010 23:14:11 -0500 Subject: [rspec-users] should raise_error(ArgumentError) resulting in NoMethodError In-Reply-To: References: Message-ID: On Aug 25, 2010, at 10:13 PM, Brian Ploetz wrote: > Environment > ------------------ > ruby 1.9.2p0 (2010-08-18 revision 29036) [x86_64-darwin10.4.0] > rspec (1.3.0) > > Code > ------- > def currency_to_dollars(currency_amount) > raise ArgumentError("Currency amount can't be nil") if currency_amount.nil? > end > > Spec > -------- > it "should raise an ArgumentError if currency_amount is nil" do > lambda { @service.currency_to_dollars(nil) }.should raise_error(ArgumentError) > end > > Results in this failure: > 1) > 'Service should raise an ArgumentError if currency_amount is nil' FAILED > expected ArgumentError, got #> This message is telling you there is no ArgumentError method, not that the constant ArgumentError is missing. The method needs to be (adding ".new"): def currency_to_dollars(currency_amount) raise ArgumentError.new("Currency amount can't be nil") if currency_amount.nil? end > test/spec/service_spec.rb:92:in `block (2 levels) in ' > > > Changing the test to either of these two variants allows the the to pass: > > lambda { @service.currency_to_dollars(nil) }.should raise_error(StandardError) > lambda { @service.currency_to_dollars(nil) }.should raise_error These pass because NoMethodError, which is what is being thrown, is a subclass of StandardError and Exception. HTH, David From Rob at AgileConsultingLLC.com Thu Aug 26 00:35:13 2010 From: Rob at AgileConsultingLLC.com (Rob Biedenharn) Date: Thu, 26 Aug 2010 00:35:13 -0400 Subject: [rspec-users] should raise_error(ArgumentError) resulting in NoMethodError In-Reply-To: References: Message-ID: <424F887A-6B89-46EE-9F77-32554F415FEC@AgileConsultingLLC.com> On Aug 26, 2010, at 12:14 AM, David Chelimsky wrote: > On Aug 25, 2010, at 10:13 PM, Brian Ploetz wrote: >> Environment >> ------------------ >> ruby 1.9.2p0 (2010-08-18 revision 29036) [x86_64-darwin10.4.0] >> rspec (1.3.0) >> >> Code >> ------- >> def currency_to_dollars(currency_amount) >> raise ArgumentError("Currency amount can't be nil") if >> currency_amount.nil? >> end >> >> Spec >> -------- >> it "should raise an ArgumentError if currency_amount is nil" do >> lambda { @service.currency_to_dollars(nil) }.should >> raise_error(ArgumentError) >> end >> >> Results in this failure: >> 1) >> 'Service should raise an ArgumentError if currency_amount is nil' >> FAILED >> expected ArgumentError, got #> `ArgumentError' for #> > > This message is telling you there is no ArgumentError method, not > that the constant ArgumentError is missing. The method needs to be > (adding ".new"): > > def currency_to_dollars(currency_amount) > raise ArgumentError.new("Currency amount can't be nil") if > currency_amount.nil? > end You might see this form, too. def currency_to_dollars(currency_amount) raise ArgumentError, "Currency amount can't be nil" if currency_amount.nil? end Note the comma that separates the arguments to raise (Kernel#raise). -Rob > >> test/spec/service_spec.rb:92:in `block (2 levels) in > (required)>' >> >> >> Changing the test to either of these two variants allows the the to >> pass: >> >> lambda { @service.currency_to_dollars(nil) }.should >> raise_error(StandardError) >> lambda { @service.currency_to_dollars(nil) }.should raise_error > > These pass because NoMethodError, which is what is being thrown, is > a subclass of StandardError and Exception. > > HTH, > David > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users Rob Biedenharn Rob at AgileConsultingLLC.com http://AgileConsultingLLC.com/ rab at GaslightSoftware.com http://GaslightSoftware.com/ From dlidstrom at gmail.com Sun Aug 22 15:10:58 2010 From: dlidstrom at gmail.com (=?ISO-8859-1?Q?Daniel_Lidstr=F6m?=) Date: Sun, 22 Aug 2010 12:10:58 -0700 (PDT) Subject: [rspec-users] Problem with spec_helper Message-ID: Hello, I am a complete newbie to both ruby and rspec. I am following the steps in the railstutorial.org book to learn ruby on rails. The current step involves setting up rspec for the tests, and this is where I am stuck. Here's what I am doing: $ cat spec/controllers/pages_controller_spec.rb require 'spec_helper' describe PagesController do describe "GET 'home'" do it "should be successful" do get 'home' response.should be_success end end describe "GET 'contact'" do it "should be successful" do get 'contact' response.should be_success end end end $ rake --trace spec (in /home/daniel/programming/rails_projects/sample_app) ** Invoke spec (first_time) ** Invoke db:test:prepare (first_time) ** Invoke db:abort_if_pending_migrations (first_time) ** Invoke environment (first_time) ** Execute environment ** Execute db:abort_if_pending_migrations ** Execute db:test:prepare ** Invoke db:test:load (first_time) ** Invoke db:test:purge (first_time) ** Invoke environment ** Execute db:test:purge ** Execute db:test:load ** Invoke db:schema:load (first_time) ** Invoke environment ** Execute db:schema:load ** Execute spec ./spec/controllers/pages_controller_spec.rb:1:in `require': no such file to load -- spec_helper (LoadError) from ./spec/controllers/pages_controller_spec.rb:1 rake aborted! bundle exec /usr/bin/ruby1.8 -Ilib -Ispec "./spec/controllers/ pages_controller_spec.rb" failed /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/core/ rake_task.rb:72 /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:1112:in `verbose' /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/core/ rake_task.rb:65:in `send' /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/core/ rake_task.rb:65 /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:636:in `call' /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:636:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:631:in `each' /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:631:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:597:in `invoke_with_call_chain' /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:590:in `invoke_with_call_chain' /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:583:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2051:in `invoke_task' /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2029:in `top_level' /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2029:in `each' /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2029:in `top_level' /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2068:in `standard_exception_handling' /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2023:in `top_level' /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2001:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2068:in `standard_exception_handling' /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:1998:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/bin/rake:31 /usr/bin/rake:19:in `load' /usr/bin/rake:19 So it seems spec_helper is not being found, am I right? A search of my system (Ubuntu 10.04) shows this file in several places: $ sudo find / -name spec_helper.rb /usr/lib/ruby/gems/1.8/gems/rspec-expectations-2.0.0.beta.18/spec/ spec_helper.rb /usr/lib/ruby/gems/1.8/gems/rspec-mocks-2.0.0.beta.19/spec/ spec_helper.rb /usr/lib/ruby/gems/1.8/gems/thor-0.14.0/spec/spec_helper.rb /usr/lib/ruby/gems/1.8/gems/launchy-0.3.7/spec/spec_helper.rb /usr/lib/ruby/gems/1.8/gems/rspec-1.3.0/spec/spec_helper.rb /usr/lib/ruby/gems/1.8/gems/rspec-expectations-2.0.0.beta.19/spec/ spec_helper.rb /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/spec/ spec_helper.rb /usr/lib/ruby/gems/1.8/gems/treetop-1.4.8/spec/runtime/ interval_skip_list/spec_helper.rb /usr/lib/ruby/gems/1.8/gems/treetop-1.4.8/spec/spec_helper.rb /usr/lib/ruby/gems/1.8/gems/rspec-rails-1.3.2/generators/rspec/ templates/spec_helper.rb /usr/lib/ruby/gems/1.8/gems/rspec-rails-1.3.2/spec/spec_helper.rb /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.18/spec/ spec_helper.rb /usr/lib/ruby/gems/1.8/gems/webrat-0.7.1/spec/spec_helper.rb /usr/lib/ruby/gems/1.8/gems/webrat-0.7.1/spec/integration/merb/spec/ spec_helper.rb /usr/lib/ruby/gems/1.8/gems/webrat-0.7.1/spec/integration/mechanize/ spec/spec_helper.rb /usr/lib/ruby/gems/1.8/gems/arel-0.4.0/spec/spec_helper.rb /usr/lib/ruby/gems/1.8/gems/rspec-mocks-2.0.0.beta.18/spec/ spec_helper.rb /usr/lib/ruby/gems/1.8/gems/rack-test-0.5.4/spec/spec_helper.rb /usr/lib/ruby/gems/1.8/gems/rspec-rails-2.0.0.beta.18/lib/generators/ rspec/install/templates/spec/spec_helper.rb /usr/lib/ruby/gems/1.8/gems/rspec-rails-2.0.0.beta.18/spec/ spec_helper.rb /usr/lib/ruby/gems/1.8/gems/rspec-rails-2.0.0.beta.19/lib/generators/ rspec/install/templates/spec/spec_helper.rb /usr/lib/ruby/gems/1.8/gems/rspec-rails-2.0.0.beta.19/spec/ spec_helper.rb /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/spec/spec_helper.rb /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/spec/integration/merb/ spec/spec_helper.rb /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/spec/integration/ mechanize/spec/spec_helper.rb My Gemfile looks like this: $ cat Gemfile source 'http://rubygems.org' gem 'rails', '3.0.0.rc' # Bundle edge Rails instead: # gem 'rails', :git => 'git://github.com/rails/rails.git' gem 'sqlite3-ruby', :require => 'sqlite3' group :development, :test do gem 'rspec-rails', '>= 2.0.0.beta.19' end I have done a few web searches but I could not find anything to help me. Any help would be greatly appreciated, I am very anxious to get started with this wonderful environment! Let me know if there's any additional information needed to pinpoint the problem. Regards, Daniel Lidstr?m Stockholm, Sweden From jeremie.horhant at titinux.net Tue Aug 24 19:51:53 2010 From: jeremie.horhant at titinux.net (Titinux) Date: Tue, 24 Aug 2010 16:51:53 -0700 (PDT) Subject: [rspec-users] Controller spec with devise. Message-ID: Hello, I'm new in using RSpec and I can't figured out to spec this controller action. class OrdersController < ApplicationController before_filter :authenticate_user! def index respond_with(@orders = current_user.orders) end end When I want to spec this "@assets = Asset.all" I use "Asset.stub(:all) { [mock_asset] }" as I read in the RSpec book but with "current_user.orders" I don't know how to do. NB: I'm using Rails 3.0.0.rc2 and RSpec 2.0.0.beta.20 Thanks in advance. J?r?mie Horhant From mauricio.linhares at gmail.com Thu Aug 26 09:12:28 2010 From: mauricio.linhares at gmail.com (=?ISO-8859-1?Q?Maur=EDcio_Linhares?=) Date: Thu, 26 Aug 2010 10:12:28 -0300 Subject: [rspec-users] Default format for all requests in a spec Message-ID: Hi guys, Is there a way to define a default parameter for all requests made in a spec? I have a spec where I want all requests to be made with the "js" format but I find it rather annoying to type a ":format => 'js'" on every get/post/put/delete. Is there any other way to do this? - Maur?cio Linhares http://codeshooter.wordpress.com/ | http://twitter.com/mauriciojr From dchelimsky at gmail.com Thu Aug 26 09:16:12 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 26 Aug 2010 08:16:12 -0500 Subject: [rspec-users] Default format for all requests in a spec In-Reply-To: References: Message-ID: On Aug 26, 2010, at 8:12 AM, Maur?cio Linhares wrote: > Hi guys, > > Is there a way to define a default parameter for all requests made in a spec? > > I have a spec where I want all requests to be made with the "js" > format but I find it rather annoying to type a ":format => 'js'" on > every get/post/put/delete. Is there any other way to do this? Nope. I'd recommend making a feature request in rails for this: https://rails.lighthouseapp.com/projects/8994. From bploetz at gmail.com Thu Aug 26 09:19:35 2010 From: bploetz at gmail.com (Brian Ploetz) Date: Thu, 26 Aug 2010 06:19:35 -0700 (PDT) Subject: [rspec-users] should raise_error(ArgumentError) resulting in NoMethodError In-Reply-To: <424F887A-6B89-46EE-9F77-32554F415FEC@AgileConsultingLLC.com> References: <424F887A-6B89-46EE-9F77-32554F415FEC@AgileConsultingLLC.com> Message-ID: <8233568a-36e6-4d18-bf23-4d6cc9289b31@x21g2000yqa.googlegroups.com> *smacks head* Duh. Thanks David and Rob! On Aug 26, 12:35?am, Rob Biedenharn wrote: > On Aug 26, 2010, at 12:14 AM, David Chelimsky wrote: > > > > > On Aug 25, 2010, at 10:13 PM, Brian Ploetz wrote: > >> Environment > >> ------------------ > >> ruby 1.9.2p0 (2010-08-18 revision 29036) [x86_64-darwin10.4.0] > >> rspec (1.3.0) > > >> Code > >> ------- > >> ? ?def currency_to_dollars(currency_amount) > >> ? ? ?raise ArgumentError("Currency amount can't be nil") if ? > >> currency_amount.nil? > >> ? ?end > > >> Spec > >> -------- > >> ? ?it "should raise an ArgumentError if currency_amount is nil" do > >> ? ? ?lambda { @service.currency_to_dollars(nil) }.should ? > >> raise_error(ArgumentError) > >> ? ?end > > >> Results in this failure: > >> 1) > >> 'Service should raise an ArgumentError if currency_amount is nil' ? > >> FAILED > >> expected ArgumentError, got # >> `ArgumentError' for #> > > > This message is telling you there is no ArgumentError method, not ? > > that the constant ArgumentError is missing. The method needs to be ? > > (adding ".new"): > > > ? ?def currency_to_dollars(currency_amount) > > ? ? ?raise ArgumentError.new("Currency amount can't be nil") if ? > > currency_amount.nil? > > ? ?end > > You might see this form, too. > > ? ? def currency_to_dollars(currency_amount) > ? ? ? raise ArgumentError, "Currency amount can't be nil" if ? > currency_amount.nil? > ? ? end > > Note the comma that separates the arguments to raise (Kernel#raise). > > -Rob > > > > > > >> test/spec/service_spec.rb:92:in `block (2 levels) in >> (required)>' > > >> Changing the test to either of these two variants allows the the to ? > >> pass: > > >> ? ?lambda { @service.currency_to_dollars(nil) }.should ? > >> raise_error(StandardError) > >> ? ?lambda { @service.currency_to_dollars(nil) }.should raise_error > > > These pass because NoMethodError, which is what is being thrown, is ? > > a subclass of StandardError and Exception. > > > HTH, > > David > > _______________________________________________ > > rspec-users mailing list > > rspec-us... at rubyforge.org > >http://rubyforge.org/mailman/listinfo/rspec-users > > Rob Biedenharn ? ? ? ? ? > R... at AgileConsultingLLC.com ?http://AgileConsultingLLC.com/ > r... at GaslightSoftware.com ? ? ? ? ? ?http://GaslightSoftware.com/ > > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users From dchelimsky at gmail.com Thu Aug 26 09:21:21 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 26 Aug 2010 08:21:21 -0500 Subject: [rspec-users] Problem with spec_helper In-Reply-To: References: Message-ID: On Aug 22, 2010, at 2:10 PM, Daniel Lidstr?m wrote: > Hello, > > I am a complete newbie to both ruby and rspec. I am following the > steps in the railstutorial.org book to learn ruby on rails. The > current step involves setting up rspec for the tests, and this is > where I am stuck. Here's what I am doing: > > > $ cat spec/controllers/pages_controller_spec.rb > require 'spec_helper' > > describe PagesController do > > describe "GET 'home'" do > it "should be successful" do > get 'home' > response.should be_success > end > end > > describe "GET 'contact'" do > it "should be successful" do > get 'contact' > response.should be_success > end > end > > end > > $ rake --trace spec > (in /home/daniel/programming/rails_projects/sample_app) > ** Invoke spec (first_time) > ** Invoke db:test:prepare (first_time) > ** Invoke db:abort_if_pending_migrations (first_time) > ** Invoke environment (first_time) > ** Execute environment > ** Execute db:abort_if_pending_migrations > ** Execute db:test:prepare > ** Invoke db:test:load (first_time) > ** Invoke db:test:purge (first_time) > ** Invoke environment > ** Execute db:test:purge > ** Execute db:test:load > ** Invoke db:schema:load (first_time) > ** Invoke environment > ** Execute db:schema:load > ** Execute spec > ./spec/controllers/pages_controller_spec.rb:1:in `require': no such > file to load -- spec_helper (LoadError) > from ./spec/controllers/pages_controller_spec.rb:1 > rake aborted! > bundle exec /usr/bin/ruby1.8 -Ilib -Ispec "./spec/controllers/ > pages_controller_spec.rb" failed > /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/core/ > rake_task.rb:72 > /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:1112:in `verbose' > /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/core/ > rake_task.rb:65:in `send' > /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/core/ > rake_task.rb:65 > /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:636:in `call' > /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:636:in `execute' > /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:631:in `each' > /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:631:in `execute' > /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:597:in > `invoke_with_call_chain' > /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize' > /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:590:in > `invoke_with_call_chain' > /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:583:in `invoke' > /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2051:in > `invoke_task' > /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2029:in `top_level' > /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2029:in `each' > /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2029:in `top_level' > /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2068:in > `standard_exception_handling' > /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2023:in `top_level' > /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2001:in `run' > /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2068:in > `standard_exception_handling' > /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:1998:in `run' > /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/bin/rake:31 > /usr/bin/rake:19:in `load' > /usr/bin/rake:19 > > So it seems spec_helper is not being found, am I right? A search of my > system (Ubuntu 10.04) shows this file in several places: > > $ sudo find / -name spec_helper.rb > /usr/lib/ruby/gems/1.8/gems/rspec-expectations-2.0.0.beta.18/spec/ > spec_helper.rb > /usr/lib/ruby/gems/1.8/gems/rspec-mocks-2.0.0.beta.19/spec/ > spec_helper.rb > /usr/lib/ruby/gems/1.8/gems/thor-0.14.0/spec/spec_helper.rb > /usr/lib/ruby/gems/1.8/gems/launchy-0.3.7/spec/spec_helper.rb > /usr/lib/ruby/gems/1.8/gems/rspec-1.3.0/spec/spec_helper.rb > /usr/lib/ruby/gems/1.8/gems/rspec-expectations-2.0.0.beta.19/spec/ > spec_helper.rb > /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/spec/ > spec_helper.rb > /usr/lib/ruby/gems/1.8/gems/treetop-1.4.8/spec/runtime/ > interval_skip_list/spec_helper.rb > /usr/lib/ruby/gems/1.8/gems/treetop-1.4.8/spec/spec_helper.rb > /usr/lib/ruby/gems/1.8/gems/rspec-rails-1.3.2/generators/rspec/ > templates/spec_helper.rb > /usr/lib/ruby/gems/1.8/gems/rspec-rails-1.3.2/spec/spec_helper.rb > /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.18/spec/ > spec_helper.rb > /usr/lib/ruby/gems/1.8/gems/webrat-0.7.1/spec/spec_helper.rb > /usr/lib/ruby/gems/1.8/gems/webrat-0.7.1/spec/integration/merb/spec/ > spec_helper.rb > /usr/lib/ruby/gems/1.8/gems/webrat-0.7.1/spec/integration/mechanize/ > spec/spec_helper.rb > /usr/lib/ruby/gems/1.8/gems/arel-0.4.0/spec/spec_helper.rb > /usr/lib/ruby/gems/1.8/gems/rspec-mocks-2.0.0.beta.18/spec/ > spec_helper.rb > /usr/lib/ruby/gems/1.8/gems/rack-test-0.5.4/spec/spec_helper.rb > /usr/lib/ruby/gems/1.8/gems/rspec-rails-2.0.0.beta.18/lib/generators/ > rspec/install/templates/spec/spec_helper.rb > /usr/lib/ruby/gems/1.8/gems/rspec-rails-2.0.0.beta.18/spec/ > spec_helper.rb > /usr/lib/ruby/gems/1.8/gems/rspec-rails-2.0.0.beta.19/lib/generators/ > rspec/install/templates/spec/spec_helper.rb > /usr/lib/ruby/gems/1.8/gems/rspec-rails-2.0.0.beta.19/spec/ > spec_helper.rb > /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/spec/spec_helper.rb > /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/spec/integration/merb/ > spec/spec_helper.rb > /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/spec/integration/ > mechanize/spec/spec_helper.rb > > My Gemfile looks like this: > > > $ cat Gemfile > source 'http://rubygems.org' > > gem 'rails', '3.0.0.rc' > > # Bundle edge Rails instead: > # gem 'rails', :git => 'git://github.com/rails/rails.git' > > gem 'sqlite3-ruby', :require => 'sqlite3' > > group :development, :test do > gem 'rspec-rails', '>= 2.0.0.beta.19' > end > > > I have done a few web searches but I could not find anything to help > me. Any help would be greatly appreciated, I am very anxious to get > started with this wonderful environment! Let me know if there's any > additional information needed to pinpoint the problem. > > Regards, > > Daniel Lidstr?m > Stockholm, Sweden RSpec adds ./spec to the load path so it should find ./spec/spec_helper.rb when you say require 'spec_helper'. I've got co-workers who are using ubuntu and this problem hasn't come up, so I'm a bit mystified. Anybody else suffering this problem? From lists at ruby-forum.com Thu Aug 26 09:22:34 2010 From: lists at ruby-forum.com (Cameron Caine) Date: Thu, 26 Aug 2010 15:22:34 +0200 Subject: [rspec-users] Rails3 subdomain constraints with Cucumber and RSpec2 In-Reply-To: References: <99f553453326157c6b9401ae2c6354ec@ruby-forum.com> Message-ID: <0fd030e856ebb12d316473072e0178f4@ruby-forum.com> I updated to rc2 and RSpec beta.20 but still get an error: Failure/Error: { :get => "http://foo.example.com/account/new" }.should_not be_routable expected {:get=>"http://foo.example.com/account/new"} not to be routable, but it routes to {:controller=>"accounts", :action=>"new"} Is this a bug? Any advice? Many thanks Cameron -- Posted via http://www.ruby-forum.com/. From dchelimsky at gmail.com Thu Aug 26 09:27:05 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 26 Aug 2010 08:27:05 -0500 Subject: [rspec-users] Rails3 subdomain constraints with Cucumber and RSpec2 In-Reply-To: <0fd030e856ebb12d316473072e0178f4@ruby-forum.com> References: <99f553453326157c6b9401ae2c6354ec@ruby-forum.com> <0fd030e856ebb12d316473072e0178f4@ruby-forum.com> Message-ID: On Aug 26, 2010, at 8:22 AM, Cameron Caine wrote: > I updated to rc2 and RSpec beta.20 but still get an error: > > Failure/Error: { :get => "http://foo.example.com/account/new" > }.should_not be_routable > expected {:get=>"http://foo.example.com/account/new"} not to be > routable, but it routes to {:controller=>"accounts", :action=>"new"} Please quote all the relevant parts of the thread in each email so we don't have to go searching through the thread for context. > Is this a bug? Any advice? > > Many thanks > > Cameron From dchelimsky at gmail.com Thu Aug 26 09:28:54 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 26 Aug 2010 08:28:54 -0500 Subject: [rspec-users] Controller spec with devise. In-Reply-To: References: Message-ID: <5EAD4227-84BA-4276-AFD1-EDC4F164E672@gmail.com> On Aug 24, 2010, at 6:51 PM, Titinux wrote: > Hello, > > I'm new in using RSpec and I can't figured out to spec this controller > action. > > class OrdersController < ApplicationController > before_filter :authenticate_user! > > def index > respond_with(@orders = current_user.orders) > end > end > > When I want to spec this "@assets = Asset.all" I use "Asset.stub(:all) > { [mock_asset] }" as I read in the RSpec book but with > "current_user.orders" I don't know how to do. > > NB: I'm using Rails 3.0.0.rc2 and RSpec 2.0.0.beta.20 What is the behaviour you want to specify? From brennon at brennonbortz.com Thu Aug 26 09:25:41 2010 From: brennon at brennonbortz.com (Brennon Bortz) Date: Thu, 26 Aug 2010 14:25:41 +0100 Subject: [rspec-users] Problem with spec_helper In-Reply-To: References: Message-ID: Would not having run "rails generate rspec:install" cause this problem? On 26 Aug 2010, at 14:21, David Chelimsky wrote: > On Aug 22, 2010, at 2:10 PM, Daniel Lidstr?m wrote: > >> >> So it seems spec_helper is not being found, am I right? A search of my >> system (Ubuntu 10.04) shows this file in several places: >> > > RSpec adds ./spec to the load path so it should find ./spec/spec_helper.rb when you say require 'spec_helper'. I've got co-workers who are using ubuntu and this problem hasn't come up, so I'm a bit mystified. Anybody else suffering this problem? > Brennon Bortz Software Researcher Dundalk Institute of Technology brennon.bortz at casala.ie Ph.D. Researcher & Composer - Sonic Arts Research Centre Queen's University, Belfast brennon at brennonbortz.com / bbortz01 at qub.ac.uk -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at mattwynne.net Thu Aug 26 11:55:01 2010 From: matt at mattwynne.net (Matt Wynne) Date: Thu, 26 Aug 2010 16:55:01 +0100 Subject: [rspec-users] Controller spec with devise. Message-ID: <5gn4dxm0yhp4a7b019vpfhji.1282838101212@email.android.com> David Chelimsky wrote: >On Aug 24, 2010, at 6:51 PM, Titinux wrote: > >> Hello, >> >> I'm new in using RSpec and I can't figured out to spec this controller >> action. >> >> class OrdersController < ApplicationController >> before_filter :authenticate_user! >> >> def index >> respond_with(@orders = current_user.orders) >> end >> end >> >> When I want to spec this "@assets = Asset.all" I use "Asset.stub(:all) >> { [mock_asset] }" as I read in the RSpec book but with >> "current_user.orders" I don't know how to do. >> >> NB: I'm using Rails 3.0.0.rc2 and RSpec 2.0.0.beta.20 > >What is the behaviour you want to specify? >_______________________________________________ >rspec-users mailing list >rspec-users at rubyforge.org >http://rubyforge.org/mailman/listinfo/rspec-users From dlidstrom at gmail.com Thu Aug 26 16:21:31 2010 From: dlidstrom at gmail.com (=?ISO-8859-1?Q?Daniel_Lidstr=F6m?=) Date: Thu, 26 Aug 2010 13:21:31 -0700 (PDT) Subject: [rspec-users] Problem with spec_helper In-Reply-To: References: Message-ID: <8bbfa1f3-b557-4edb-924f-ff906059c6cc@s9g2000yqd.googlegroups.com> On 26 Aug, 15:25, Brennon Bortz wrote: > Would not having run "rails generate rspec:install" cause this problem? > > On 26 Aug 2010, at 14:21, David Chelimsky wrote: > > > On Aug 22, 2010, at 2:10 PM, Daniel Lidstr?m wrote: > > >> > >> So it seems spec_helper is not being found, am I right? A search of my > >> system (Ubuntu 10.04) shows this file in several places: > >> > > > RSpec adds ./spec to the load path so it should find ./spec/spec_helper.rb when you say require 'spec_helper'. I've got co-workers who are using ubuntu and this problem hasn't come up, so I'm a bit mystified. Anybody else suffering this problem? > > > That did the trick Brennon: daniel at ubuntu/home/daniel/programming/rails_projects/sample_app$ rails generate rspec:install create .rspec exist spec create spec/spec_helper.rb create autotest create autotest/discover.rb daniel at ubuntu/home/daniel/programming/rails_projects/sample_app$ ls spec/spec_helper.rb spec/spec_helper.rb I missed this step in the railstutorial.org :-( Anyway, thanks a lot! Daniel From dwayne.purper at gmail.com Thu Aug 26 09:35:14 2010 From: dwayne.purper at gmail.com (dwayne) Date: Thu, 26 Aug 2010 06:35:14 -0700 (PDT) Subject: [rspec-users] rspec can not be found Message-ID: <9a63f396-d87d-4006-a350-c809df8f86c6@x42g2000yqx.googlegroups.com> Hi guys: I'm trying to get my RVM/Rails 2 and 3 mixed environment set up, and I'm still running into problems. Not sure if that's related to rspec not being found, but here's what's happening: $ rake spec --trace (in /Users/dwayne/Sites/casehandler_rails) ** Invoke spec (first_time) ** Invoke db:test:prepare (first_time) ** Invoke db:abort_if_pending_migrations (first_time) ** Invoke environment (first_time) ** Execute environment ** Execute db:abort_if_pending_migrations ** Execute db:test:prepare ** Invoke db:test:load (first_time) ** Invoke db:test:purge (first_time) ** Invoke environment ** Execute db:test:purge ** Execute db:test:load ** Invoke db:schema:load (first_time) ** Invoke environment ** Execute db:schema:load ** Execute spec rake aborted! ******************************************************************************** * You are trying to run an rspec rake task defined in * /Users/dwayne/Sites/casehandler_rails/lib/tasks/rspec.rake, * but rspec can not be found in vendor/gems, vendor/plugins or system gems. ******************************************************************************** /Users/dwayne/Sites/casehandler_rails/lib/tasks/rspec.rake:33:in `initialize' /Users/dwayne/.rvm/gems/ruby-1.8.7-p174 at rails3/gems/rake-0.8.7/lib/ rake.rb:636:in `call' /Users/dwayne/.rvm/gems/ruby-1.8.7-p174 at rails3/gems/rake-0.8.7/lib/ rake.rb:636:in `execute' /Users/dwayne/.rvm/gems/ruby-1.8.7-p174 at rails3/gems/rake-0.8.7/lib/ rake.rb:631:in `each' /Users/dwayne/.rvm/gems/ruby-1.8.7-p174 at rails3/gems/rake-0.8.7/lib/ rake.rb:631:in `execute' /Users/dwayne/.rvm/gems/ruby-1.8.7-p174 at rails3/gems/rake-0.8.7/lib/ rake.rb:597:in `invoke_with_call_chain' /Users/dwayne/.rvm/rubies/ruby-1.8.7-p174/lib/ruby/1.8/monitor.rb: 242:in `synchronize' ... Gemfile includes: group :development, :test do gem 'rspec' gem 'rspec-rails', '>= 2.0.0.beta.19' gem 'webrat' gem 'capybara' gem 'database_cleaner' gem 'gherkin', '2.1.5' gem 'cucumber-rails', '>=0.3.2' gem 'cucumber', '>=0.8.5' gem 'spork' gem 'launchy' # So you can do Then show me the page end $ bundle show ... * rspec (2.0.0.beta.19) * rspec-core (2.0.0.beta.19) * rspec-expectations (2.0.0.beta.19) * rspec-mocks (2.0.0.beta.19) * rspec-rails (2.0.0.beta.19) ... I've run the install scripts, etc. Is there a reason the gem isn't being found? Thanks. From dchelimsky at gmail.com Thu Aug 26 19:16:26 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 26 Aug 2010 18:16:26 -0500 Subject: [rspec-users] rspec can not be found In-Reply-To: <9a63f396-d87d-4006-a350-c809df8f86c6@x42g2000yqx.googlegroups.com> References: <9a63f396-d87d-4006-a350-c809df8f86c6@x42g2000yqx.googlegroups.com> Message-ID: On Aug 26, 2010, at 8:35 AM, dwayne wrote: > Hi guys: > > I'm trying to get my RVM/Rails 2 and 3 mixed environment set up, and > I'm still running into problems. Not sure if that's related to rspec > not being found, but here's what's happening: > > $ rake spec --trace > (in /Users/dwayne/Sites/casehandler_rails) > ** Invoke spec (first_time) > ** Invoke db:test:prepare (first_time) > ** Invoke db:abort_if_pending_migrations (first_time) > ** Invoke environment (first_time) > ** Execute environment > ** Execute db:abort_if_pending_migrations > ** Execute db:test:prepare > ** Invoke db:test:load (first_time) > ** Invoke db:test:purge (first_time) > ** Invoke environment > ** Execute db:test:purge > ** Execute db:test:load > ** Invoke db:schema:load (first_time) > ** Invoke environment > ** Execute db:schema:load > ** Execute spec > rake aborted! > > ******************************************************************************** > * You are trying to run an rspec rake task defined in > * /Users/dwayne/Sites/casehandler_rails/lib/tasks/rspec.rake, > * but rspec can not be found in vendor/gems, vendor/plugins or system > gems. > ******************************************************************************** This is coming from a rake file that should be removed: lib/tasks/rspec.rake. Try removing that file and see what happens. > /Users/dwayne/Sites/casehandler_rails/lib/tasks/rspec.rake:33:in > `initialize' > /Users/dwayne/.rvm/gems/ruby-1.8.7-p174 at rails3/gems/rake-0.8.7/lib/ > rake.rb:636:in `call' > /Users/dwayne/.rvm/gems/ruby-1.8.7-p174 at rails3/gems/rake-0.8.7/lib/ > rake.rb:636:in `execute' > /Users/dwayne/.rvm/gems/ruby-1.8.7-p174 at rails3/gems/rake-0.8.7/lib/ > rake.rb:631:in `each' > /Users/dwayne/.rvm/gems/ruby-1.8.7-p174 at rails3/gems/rake-0.8.7/lib/ > rake.rb:631:in `execute' > /Users/dwayne/.rvm/gems/ruby-1.8.7-p174 at rails3/gems/rake-0.8.7/lib/ > rake.rb:597:in `invoke_with_call_chain' > /Users/dwayne/.rvm/rubies/ruby-1.8.7-p174/lib/ruby/1.8/monitor.rb: > 242:in `synchronize' > ... > > > Gemfile includes: > > group :development, :test do > gem 'rspec' > gem 'rspec-rails', '>= 2.0.0.beta.19' > gem 'webrat' > gem 'capybara' > gem 'database_cleaner' > gem 'gherkin', '2.1.5' > gem 'cucumber-rails', '>=0.3.2' > gem 'cucumber', '>=0.8.5' > gem 'spork' > gem 'launchy' # So you can do Then show me the page > end > > > $ bundle show > ... > * rspec (2.0.0.beta.19) > * rspec-core (2.0.0.beta.19) > * rspec-expectations (2.0.0.beta.19) > * rspec-mocks (2.0.0.beta.19) > * rspec-rails (2.0.0.beta.19) > ... > > I've run the install scripts, etc. > > Is there a reason the gem isn't being found? > > Thanks. > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users From lists at ruby-forum.com Fri Aug 27 01:43:36 2010 From: lists at ruby-forum.com (Zhenning Guan) Date: Fri, 27 Aug 2010 07:43:36 +0200 Subject: [rspec-users] there should be one test or two? Message-ID: in real world, when user deposit money into their bank, bank have money and can check deposit record. so what would it be in rspec? it 'should be deposit $10' user.bank.deposit(10) user.bank.deposit.saving.should == 10 end about test , should be deposit $10 is clear? maybe 'should deposit $10 success'? and when deposit, we should have a deposit record. added another test? it 'should be a deposit record when deposit $10' user.bank.deposit(10) user.deposit_record.should == #something. end or just mixed it in one test? it 'should be deposit $10' user.bank.deposit(10) user.bank.deposit.saving.should == 10 user.deposit_record.should == #something. end -- Posted via http://www.ruby-forum.com/. From jeremie.horhant at titinux.net Fri Aug 27 06:35:37 2010 From: jeremie.horhant at titinux.net (Titinux) Date: Fri, 27 Aug 2010 03:35:37 -0700 (PDT) Subject: [rspec-users] Controller spec with devise. In-Reply-To: <5EAD4227-84BA-4276-AFD1-EDC4F164E672@gmail.com> References: <5EAD4227-84BA-4276-AFD1-EDC4F164E672@gmail.com> Message-ID: I tink it's @orders should be an array of orders from current_user.orders. describe OrdersController do include Devise::TestHelpers def mock_order(stubs={}) @mock_order ||= mock_model(Order, stubs).as_null_object end describe "GET index" do it "assigns user's orders to @orders" do current_user.stub!(:orders).and_return([mock_order]) get :index assigns(:orders).should eq([mock_order]) end end end I tried with this code but the test failed with this error : Failure/Error: current_user.stub!(:orders).and_return([mock_order]) undefined local variable or method `current_user' for # On 26 ao?t, 15:28, David Chelimsky wrote: > On Aug 24, 2010, at 6:51 PM, Titinux wrote: > > > > > Hello, > > > I'm new in using RSpec and I can't figured out to spec this controller > > action. > > > class OrdersController < ApplicationController > > ?before_filter :authenticate_user! > > > ?def index > > ? ?respond_with(@orders = current_user.orders) > > ?end > > end > > > When I want to spec this "@assets = Asset.all" I use "Asset.stub(:all) > > { [mock_asset] }" as I read in the RSpec book but with > > "current_user.orders" I don't know how to do. > > > NB: I'm using Rails 3.0.0.rc2 and RSpec 2.0.0.beta.20 > > What is the behaviour you want to specify? > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users From brennon at brennonbortz.com Fri Aug 27 07:47:21 2010 From: brennon at brennonbortz.com (Brennon Bortz) Date: Fri, 27 Aug 2010 12:47:21 +0100 Subject: [rspec-users] Autotest will run features, but not specs In-Reply-To: References: <5EAD4227-84BA-4276-AFD1-EDC4F164E672@gmail.com> Message-ID: <4A619CFA-5221-4BB0-8AD5-E56B95E12D86@brennonbortz.com> Not sure what I must have bumped, but autotest won't run any specs--only features. No errors are given on startup. I've taken "export AUTOFEATURE=true" out of my ./bashrc file--now I just get a blank screen when running autotest. Adding "export RSPEC=true" to .bashrc doesn't change anything either. # ~/.autotest require 'autotest/growl' Autotest.add_hook(:initialize) { |at| at.add_exception %r{^\.git} # ignore Version Control System at.add_exception %r{^./tmp} # ignore temp files, lest autotest will run again, and again... # at.clear_mappings # take out the default (test/test*rb) at.add_mapping(%r{^lib/.*\.rb$}) {|f, _| Dir['spec/**/*.rb'] } nil } Autotest.add_hook :initialize do |at| at.add_mapping(%r%^spec/(integration)/.*rb$%) {|filename, _| filename } end # {RAILS_ROOT}/autotest/.discover.rb Autotest.add_discovery { "rails" } Autotest.add_discovery { "rspec2" } # {RAILS_ROOT/.rspec --format nested --color Output when running autotest: $ RSPEC=true autotest (Not running features. To run features in autotest, set AUTOFEATURE=true.) loading autotest/rails -------------------------------------------------------------------------------- And, here are my bundled gems: Gems included by the bundle: * abstract (1.0.0) * actionmailer (3.0.0.rc) * actionpack (3.0.0.rc) * activemodel (3.0.0.rc) * activerecord (3.0.0.rc) * activeresource (3.0.0.rc) * activesupport (3.0.0.rc) * arel (0.4.0) * builder (2.1.2) * bundler (1.0.0.rc.6) * capybara (0.3.9) * cucumber (0.8.5) * cucumber-rails (0.3.2) * culerity (0.2.12) * diff-lcs (1.1.2) * erubis (2.6.6) * ffi (0.6.3) * gherkin (2.1.5) * i18n (0.4.1) * json_pure (1.4.6) * mail (2.2.5) * mime-types (1.16) * nokogiri (1.4.3.1) * polyglot (0.3.1) * rack (1.2.1) * rack-mount (0.6.12) * rack-test (0.5.4) * rails (3.0.0.rc) * railties (3.0.0.rc) * rake (0.8.7) * rspec (2.0.0.beta.20) * rspec-core (2.0.0.beta.20) * rspec-expectations (2.0.0.beta.20) * rspec-mocks (2.0.0.beta.20) * rspec-rails (2.0.0.beta.20) * rubyzip (0.9.4) * selenium-webdriver (0.0.28) * sqlite3-ruby (1.3.1) * term-ansicolor (1.0.5) * thor (0.14.0) * treetop (1.4.8) * trollop (1.16.2) * tzinfo (0.3.23) This is driving me up the wall...any ideas? Best, Brennon Brennon Bortz Software Researcher Dundalk Institute of Technology brennon.bortz at casala.ie Ph.D. Researcher & Composer - Sonic Arts Research Centre Queen's University, Belfast brennon at brennonbortz.com / bbortz01 at qub.ac.uk From brennon at brennonbortz.com Fri Aug 27 07:49:16 2010 From: brennon at brennonbortz.com (Brennon Bortz) Date: Fri, 27 Aug 2010 12:49:16 +0100 Subject: [rspec-users] Autotest will run features, but not specs In-Reply-To: <4A619CFA-5221-4BB0-8AD5-E56B95E12D86@brennonbortz.com> References: <5EAD4227-84BA-4276-AFD1-EDC4F164E672@gmail.com> <4A619CFA-5221-4BB0-8AD5-E56B95E12D86@brennonbortz.com> Message-ID: <77F34980-477C-4E0F-A48C-2B5316B253CD@brennonbortz.com> I should point out that autotest detects changes to specs just fine and reloads accordingly--but still only gives blank output. Thanks again, Brennon Brennon Bortz Software Researcher Dundalk Institute of Technology brennon.bortz at casala.ie Ph.D. Researcher & Composer - Sonic Arts Research Centre Queen's University, Belfast brennon at brennonbortz.com / bbortz01 at qub.ac.uk From dchelimsky at gmail.com Fri Aug 27 09:06:23 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 27 Aug 2010 08:06:23 -0500 Subject: [rspec-users] Autotest will run features, but not specs In-Reply-To: <4A619CFA-5221-4BB0-8AD5-E56B95E12D86@brennonbortz.com> References: <5EAD4227-84BA-4276-AFD1-EDC4F164E672@gmail.com> <4A619CFA-5221-4BB0-8AD5-E56B95E12D86@brennonbortz.com> Message-ID: <9E1AF3ED-C464-4037-A3A7-553806CD2CDB@gmail.com> On Aug 27, 2010, at 6:47 AM, Brennon Bortz wrote: > Not sure what I must have bumped, but autotest won't run any specs--only features. No errors are given on startup. I've taken "export AUTOFEATURE=true" out of my ./bashrc file--now I just get a blank screen when running autotest. Adding "export RSPEC=true" to .bashrc doesn't change anything either. > > # ~/.autotest > require 'autotest/growl' > > Autotest.add_hook(:initialize) { |at| > at.add_exception %r{^\.git} # ignore Version Control System > at.add_exception %r{^./tmp} # ignore temp files, lest autotest will run again, and again... > # at.clear_mappings # take out the default (test/test*rb) > at.add_mapping(%r{^lib/.*\.rb$}) {|f, _| > Dir['spec/**/*.rb'] > } > nil > } > > Autotest.add_hook :initialize do |at| > at.add_mapping(%r%^spec/(integration)/.*rb$%) {|filename, _| > filename > } > end > > # {RAILS_ROOT}/autotest/.discover.rb > Autotest.add_discovery { "rails" } > Autotest.add_discovery { "rspec2" } > > # {RAILS_ROOT/.rspec > --format nested > --color > > Output when running autotest: > > $ RSPEC=true autotest > (Not running features. To run features in autotest, set AUTOFEATURE=true.) > loading autotest/rails > > > -------------------------------------------------------------------------------- > > > And, here are my bundled gems: > > Gems included by the bundle: > * abstract (1.0.0) > * actionmailer (3.0.0.rc) > * actionpack (3.0.0.rc) > * activemodel (3.0.0.rc) > * activerecord (3.0.0.rc) > * activeresource (3.0.0.rc) > * activesupport (3.0.0.rc) > * arel (0.4.0) > * builder (2.1.2) > * bundler (1.0.0.rc.6) > * capybara (0.3.9) > * cucumber (0.8.5) > * cucumber-rails (0.3.2) > * culerity (0.2.12) > * diff-lcs (1.1.2) > * erubis (2.6.6) > * ffi (0.6.3) > * gherkin (2.1.5) > * i18n (0.4.1) > * json_pure (1.4.6) > * mail (2.2.5) > * mime-types (1.16) > * nokogiri (1.4.3.1) > * polyglot (0.3.1) > * rack (1.2.1) > * rack-mount (0.6.12) > * rack-test (0.5.4) > * rails (3.0.0.rc) > * railties (3.0.0.rc) > * rake (0.8.7) > * rspec (2.0.0.beta.20) > * rspec-core (2.0.0.beta.20) > * rspec-expectations (2.0.0.beta.20) > * rspec-mocks (2.0.0.beta.20) > * rspec-rails (2.0.0.beta.20) > * rubyzip (0.9.4) > * selenium-webdriver (0.0.28) > * sqlite3-ruby (1.3.1) > * term-ansicolor (1.0.5) > * thor (0.14.0) > * treetop (1.4.8) > * trollop (1.16.2) > * tzinfo (0.3.23) > > This is driving me up the wall...any ideas? 1. Get rid of 'Autotest.add_discovery { "rails" }' from ./autotest/discover.rb. 2. Add autotest-rails to the Gemfile. If any of the gems listed in the Gemfile have :path or :git options, you need to run "bundle exec autotest". HTH, David From dchelimsky at gmail.com Fri Aug 27 09:11:04 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 27 Aug 2010 08:11:04 -0500 Subject: [rspec-users] Controller spec with devise. In-Reply-To: References: <5EAD4227-84BA-4276-AFD1-EDC4F164E672@gmail.com> Message-ID: <05E6E045-A299-4420-A0E2-5E32F3AD7404@gmail.com> On Aug 27, 2010, at 5:35 AM, Titinux wrote: > I tink it's @orders should be an array of orders from > current_user.orders. > > describe OrdersController do > include Devise::TestHelpers > > def mock_order(stubs={}) > @mock_order ||= mock_model(Order, stubs).as_null_object > end > > describe "GET index" do > it "assigns user's orders to @orders" do > current_user.stub!(:orders).and_return([mock_order]) > > get :index > assigns(:orders).should eq([mock_order]) > end > end > end > > I tried with this code but the test failed with this error : > > Failure/Error: current_user.stub!(:orders).and_return([mock_order]) > undefined local variable or method `current_user' for > # Right. That's because there is no current_user in the example, it's in the controller. Make sense? So you need to stub current_user in the controller as well: user = double('user') controller.stub(:current_user) { user } user.stub(:orders) { [mock_order] } get :index assigns(:orders).should eq([mock_order]) HTH, David > On 26 ao?t, 15:28, David Chelimsky wrote: >> On Aug 24, 2010, at 6:51 PM, Titinux wrote: >> >> >> >>> Hello, >> >>> I'm new in using RSpec and I can't figured out to spec this controller >>> action. >> >>> class OrdersController < ApplicationController >>> before_filter :authenticate_user! >> >>> def index >>> respond_with(@orders = current_user.orders) >>> end >>> end >> >>> When I want to spec this "@assets = Asset.all" I use "Asset.stub(:all) >>> { [mock_asset] }" as I read in the RSpec book but with >>> "current_user.orders" I don't know how to do. >> >>> NB: I'm using Rails 3.0.0.rc2 and RSpec 2.0.0.beta.20 >> >> What is the behaviour you want to specify? >> _______________________________________________ >> rspec-users mailing list >> rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users From brennon at brennonbortz.com Fri Aug 27 09:29:59 2010 From: brennon at brennonbortz.com (Brennon Bortz) Date: Fri, 27 Aug 2010 14:29:59 +0100 Subject: [rspec-users] Autotest will run features, but not specs In-Reply-To: <9E1AF3ED-C464-4037-A3A7-553806CD2CDB@gmail.com> References: <5EAD4227-84BA-4276-AFD1-EDC4F164E672@gmail.com> <4A619CFA-5221-4BB0-8AD5-E56B95E12D86@brennonbortz.com> <9E1AF3ED-C464-4037-A3A7-553806CD2CDB@gmail.com> Message-ID: <3E6D070C-266C-4354-AA54-3B9864A58EF5@brennonbortz.com> Strange...that does work, but now autotest seems caught in an infinite loop. When I run autospec, the specs run, then the features, then the features again...and again...and again...and so on. If I run autotest as follows: "AUTOFEATURE=false autotest", I don't have the problem. Any other ideas? Many thanks, Brennon On 27 Aug 2010, at 14:06, David Chelimsky wrote: > On Aug 27, 2010, at 6:47 AM, Brennon Bortz wrote: > >> Not sure what I must have bumped, but autotest won't run any specs--only features. No errors are given on startup. I've taken "export AUTOFEATURE=true" out of my ./bashrc file--now I just get a blank screen when running autotest. Adding "export RSPEC=true" to .bashrc doesn't change anything either. > > 1. Get rid of 'Autotest.add_discovery { "rails" }' from ./autotest/discover.rb. > 2. Add autotest-rails to the Gemfile. > > If any of the gems listed in the Gemfile have :path or :git options, you need to run "bundle exec autotest". > > HTH, > David > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users Brennon Bortz Software Researcher Dundalk Institute of Technology brennon.bortz at casala.ie Ph.D. Researcher & Composer - Sonic Arts Research Centre Queen's University, Belfast brennon at brennonbortz.com / bbortz01 at qub.ac.uk From brennon at brennonbortz.com Fri Aug 27 09:37:54 2010 From: brennon at brennonbortz.com (Brennon Bortz) Date: Fri, 27 Aug 2010 14:37:54 +0100 Subject: [rspec-users] Autotest will run features, but not specs In-Reply-To: <3E6D070C-266C-4354-AA54-3B9864A58EF5@brennonbortz.com> References: <5EAD4227-84BA-4276-AFD1-EDC4F164E672@gmail.com> <4A619CFA-5221-4BB0-8AD5-E56B95E12D86@brennonbortz.com> <9E1AF3ED-C464-4037-A3A7-553806CD2CDB@gmail.com> <3E6D070C-266C-4354-AA54-3B9864A58EF5@brennonbortz.com> Message-ID: <5D6BAADD-5D54-47E0-A82D-A16DEF8AD807@brennonbortz.com> And now (I haven't touched anything...seriously!), even "AUTOFEATURE=false autotest" gives me an endless loop of spec tests... On 27 Aug 2010, at 14:29, Brennon Bortz wrote: > Strange...that does work, but now autotest seems caught in an infinite loop. When I run autospec, the specs run, then the features, then the features again...and again...and again...and so on. If I run autotest as follows: "AUTOFEATURE=false autotest", I don't have the problem. Any other ideas? > > Many thanks, > Brennon > > On 27 Aug 2010, at 14:06, David Chelimsky wrote: > >> On Aug 27, 2010, at 6:47 AM, Brennon Bortz wrote: >> >>> Not sure what I must have bumped, but autotest won't run any specs--only features. No errors are given on startup. I've taken "export AUTOFEATURE=true" out of my ./bashrc file--now I just get a blank screen when running autotest. Adding "export RSPEC=true" to .bashrc doesn't change anything either. >> >> 1. Get rid of 'Autotest.add_discovery { "rails" }' from ./autotest/discover.rb. >> 2. Add autotest-rails to the Gemfile. >> >> If any of the gems listed in the Gemfile have :path or :git options, you need to run "bundle exec autotest". >> >> HTH, >> David >> >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users > > Brennon Bortz > Software Researcher > Dundalk Institute of Technology > brennon.bortz at casala.ie > Ph.D. Researcher & Composer - Sonic Arts Research Centre > Queen's University, Belfast > brennon at brennonbortz.com / bbortz01 at qub.ac.uk > Brennon Bortz Software Researcher Dundalk Institute of Technology brennon.bortz at casala.ie Ph.D. Researcher & Composer - Sonic Arts Research Centre Queen's University, Belfast brennon at brennonbortz.com / bbortz01 at qub.ac.uk From dchelimsky at gmail.com Fri Aug 27 09:44:36 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 27 Aug 2010 08:44:36 -0500 Subject: [rspec-users] Autotest will run features, but not specs In-Reply-To: <5D6BAADD-5D54-47E0-A82D-A16DEF8AD807@brennonbortz.com> References: <5EAD4227-84BA-4276-AFD1-EDC4F164E672@gmail.com> <4A619CFA-5221-4BB0-8AD5-E56B95E12D86@brennonbortz.com> <9E1AF3ED-C464-4037-A3A7-553806CD2CDB@gmail.com> <3E6D070C-266C-4354-AA54-3B9864A58EF5@brennonbortz.com> <5D6BAADD-5D54-47E0-A82D-A16DEF8AD807@brennonbortz.com> Message-ID: <2D455128-FFCD-4616-B3A1-678901E99CC7@gmail.com> On Aug 27, 2010, at 8:37 AM, Brennon Bortz wrote: > On 27 Aug 2010, at 14:29, Brennon Bortz wrote: > >> On 27 Aug 2010, at 14:06, David Chelimsky wrote: >> >>> On Aug 27, 2010, at 6:47 AM, Brennon Bortz wrote: >>> >>>> Not sure what I must have bumped, but autotest won't run any specs--only features. No errors are given on startup. I've taken "export AUTOFEATURE=true" out of my ./bashrc file--now I just get a blank screen when running autotest. Adding "export RSPEC=true" to .bashrc doesn't change anything either. >>> >>> 1. Get rid of 'Autotest.add_discovery { "rails" }' from ./autotest/discover.rb. >>> 2. Add autotest-rails to the Gemfile. >>> >>> If any of the gems listed in the Gemfile have :path or :git options, you need to run "bundle exec autotest". >>> >>> HTH, >>> DavidStrange...that does work, but now autotest seems caught in an infinite loop. When I run autospec, the specs run, then the features, then the features again...and again...and again...and so on. If I run autotest as follows: "AUTOFEATURE=false autotest", I don't have the problem. Any other ideas? > And now (I haven't touched anything...seriously!), even "AUTOFEATURE=false autotest" gives me an endless loop of spec tests... (I moved your posts to the bottom so we can read them in order. Please post at the bottom or inline.) I've seen this happen when files are generated during a spec run. What's in spec/spec.opts and cucumber.yml? From brennon at brennonbortz.com Fri Aug 27 09:48:48 2010 From: brennon at brennonbortz.com (Brennon Bortz) Date: Fri, 27 Aug 2010 14:48:48 +0100 Subject: [rspec-users] Autotest will run features, but not specs In-Reply-To: <2D455128-FFCD-4616-B3A1-678901E99CC7@gmail.com> References: <5EAD4227-84BA-4276-AFD1-EDC4F164E672@gmail.com> <4A619CFA-5221-4BB0-8AD5-E56B95E12D86@brennonbortz.com> <9E1AF3ED-C464-4037-A3A7-553806CD2CDB@gmail.com> <3E6D070C-266C-4354-AA54-3B9864A58EF5@brennonbortz.com> <5D6BAADD-5D54-47E0-A82D-A16DEF8AD807@brennonbortz.com> <2D455128-FFCD-4616-B3A1-678901E99CC7@gmail.com> Message-ID: On 27 Aug 2010, at 14:44, David Chelimsky wrote: > On Aug 27, 2010, at 8:37 AM, Brennon Bortz wrote: > >> On 27 Aug 2010, at 14:29, Brennon Bortz wrote: >> >>> On 27 Aug 2010, at 14:06, David Chelimsky wrote: >>> >>>> On Aug 27, 2010, at 6:47 AM, Brennon Bortz wrote: >>>> >>>>> Not sure what I must have bumped, but autotest won't run any specs--only features. No errors are given on startup. I've taken "export AUTOFEATURE=true" out of my ./bashrc file--now I just get a blank screen when running autotest. Adding "export RSPEC=true" to .bashrc doesn't change anything either. >>>> >>>> 1. Get rid of 'Autotest.add_discovery { "rails" }' from ./autotest/discover.rb. >>>> 2. Add autotest-rails to the Gemfile. >>>> >>>> If any of the gems listed in the Gemfile have :path or :git options, you need to run "bundle exec autotest". >>>> >>>> HTH, >>>> DavidStrange...that does work, but now autotest seems caught in an infinite loop. When I run autospec, the specs run, then the features, then the features again...and again...and again...and so on. If I run autotest as follows: "AUTOFEATURE=false autotest", I don't have the problem. Any other ideas? >> And now (I haven't touched anything...seriously!), even "AUTOFEATURE=false autotest" gives me an endless loop of spec tests... > > (I moved your posts to the bottom so we can read them in order. Please post at the bottom or inline.) > > I've seen this happen when files are generated during a spec run. What's in spec/spec.opts and cucumber.yml? No spec.opts file, and just the default cucumber.yml file (I believe): <% rerun = File.file?('rerun.txt') ? IO.read('rerun.txt') : "" rerun_opts = rerun.to_s.strip.empty? ? "--format #{ENV['CUCUMBER_FORMAT'] || 'progress'} features" : "--format #{ENV['CUCUMBER_FORMAT'] || 'pretty'} #{rerun}" std_opts = "--format #{ENV['CUCUMBER_FORMAT'] || 'progress'} --strict --tags ~@wip" %> default: <%= std_opts %> features wip: --tags @wip:3 --wip features rerun: <%= rerun_opts %> --format rerun --out rerun.txt --strict --tags ~@wip From dchelimsky at gmail.com Fri Aug 27 10:20:52 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 27 Aug 2010 09:20:52 -0500 Subject: [rspec-users] Autotest will run features, but not specs In-Reply-To: References: <5EAD4227-84BA-4276-AFD1-EDC4F164E672@gmail.com> <4A619CFA-5221-4BB0-8AD5-E56B95E12D86@brennonbortz.com> <9E1AF3ED-C464-4037-A3A7-553806CD2CDB@gmail.com> <3E6D070C-266C-4354-AA54-3B9864A58EF5@brennonbortz.com> <5D6BAADD-5D54-47E0-A82D-A16DEF8AD807@brennonbortz.com> <2D455128-FFCD-4616-B3A1-678901E99CC7@gmail.com> Message-ID: On Aug 27, 2010, at 8:48 AM, Brennon Bortz wrote: > On 27 Aug 2010, at 14:44, David Chelimsky wrote: > >> On Aug 27, 2010, at 8:37 AM, Brennon Bortz wrote: >> >>> On 27 Aug 2010, at 14:29, Brennon Bortz wrote: >>> >>>> On 27 Aug 2010, at 14:06, David Chelimsky wrote: >>>> >>>>> On Aug 27, 2010, at 6:47 AM, Brennon Bortz wrote: >>>>> >>>>>> Not sure what I must have bumped, but autotest won't run any specs--only features. No errors are given on startup. I've taken "export AUTOFEATURE=true" out of my ./bashrc file--now I just get a blank screen when running autotest. Adding "export RSPEC=true" to .bashrc doesn't change anything either. >>>>> >>>>> 1. Get rid of 'Autotest.add_discovery { "rails" }' from ./autotest/discover.rb. >>>>> 2. Add autotest-rails to the Gemfile. >>>>> >>>>> If any of the gems listed in the Gemfile have :path or :git options, you need to run "bundle exec autotest". >>>>> >>>>> HTH, >>>>> DavidStrange...that does work, but now autotest seems caught in an infinite loop. When I run autospec, the specs run, then the features, then the features again...and again...and again...and so on. If I run autotest as follows: "AUTOFEATURE=false autotest", I don't have the problem. Any other ideas? >>> And now (I haven't touched anything...seriously!), even "AUTOFEATURE=false autotest" gives me an endless loop of spec tests... >> >> (I moved your posts to the bottom so we can read them in order. Please post at the bottom or inline.) >> >> I've seen this happen when files are generated during a spec run. What's in spec/spec.opts and cucumber.yml? > > No spec.opts file, and just the default cucumber.yml file (I believe): > > <% > rerun = File.file?('rerun.txt') ? IO.read('rerun.txt') : "" > rerun_opts = rerun.to_s.strip.empty? ? "--format #{ENV['CUCUMBER_FORMAT'] || 'progress'} features" : "--format #{ENV['CUCUMBER_FORMAT'] || 'pretty'} #{rerun}" > std_opts = "--format #{ENV['CUCUMBER_FORMAT'] || 'progress'} --strict --tags ~@wip" > %> > default: <%= std_opts %> features > wip: --tags @wip:3 --wip features > rerun: <%= rerun_opts %> --format rerun --out rerun.txt --strict --tags ~@wip Unless you're running cucumber with --profile rerun, this shouldn't be a problem. Do any of your specs generate files? Also, did you try both "autotest" and "bundle exec autotest" with the same results? From sixtimesnine at gmail.com Fri Aug 27 12:42:25 2010 From: sixtimesnine at gmail.com (theLemcke) Date: Fri, 27 Aug 2010 09:42:25 -0700 (PDT) Subject: [rspec-users] Problem running "spec spec" or "rake spec" (does nothing) Message-ID: I have an unusual problem. I'm adding test coverage to my project, and I'd like to be able to run "rake spec" to run all the tests in the /spec folder of the app, but whenever I use the commands "spec spec" or "rake spec" I get no return value (rubymine returns "no tests found" if I use that). However, spec spec/*.spec works, and running the individual specs work. Any insight would be greatly appreciated. -Chris Lemcke From cflipse at gmail.com Fri Aug 27 13:45:49 2010 From: cflipse at gmail.com (Chris Flipse) Date: Fri, 27 Aug 2010 13:45:49 -0400 Subject: [rspec-users] Problem running "spec spec" or "rake spec" (does nothing) In-Reply-To: References: Message-ID: both rake spec and spec itself expect a spec file to be named *_spec.rb, not *.spec On Fri, Aug 27, 2010 at 12:42 PM, theLemcke wrote: > I have an unusual problem. I'm adding test coverage to my project, > and I'd like to be able to run "rake spec" to run all the tests in > the /spec folder of the app, but whenever I use the commands "spec > spec" or "rake spec" I get no return value (rubymine returns "no tests > found" if I use that). However, spec spec/*.spec works, and running > the individual specs work. Any insight would be greatly appreciated. > > > -Chris Lemcke > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > -- // anything worth taking seriously is worth making fun of // http://blog.devcaffeine.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at mattwynne.net Fri Aug 27 11:42:55 2010 From: matt at mattwynne.net (Matt Wynne) Date: Fri, 27 Aug 2010 16:42:55 +0100 Subject: [rspec-users] there should be one test or two? In-Reply-To: References: Message-ID: <538F7A03-A1F8-4BD8-B122-28DAB384E8D0@mattwynne.net> Hi Zhenning, One assertion per test [1] is a good rule of thumb, but don't get too hung up about it. [1] http://blog.jayfields.com/2007/06/testing-one-assertion-per-test.html On 27 Aug 2010, at 06:43, Zhenning Guan wrote: > in real world, when user deposit money into their bank, bank have money > and can check deposit record. so what would it be in rspec? > > it 'should be deposit $10' > user.bank.deposit(10) > user.bank.deposit.saving.should == 10 > end > > about test , should be deposit $10 is clear? maybe 'should deposit $10 > success'? > > and when deposit, we should have a deposit record. added another test? > > it 'should be a deposit record when deposit $10' > user.bank.deposit(10) > user.deposit_record.should == #something. > end > > or just mixed it in one test? > > it 'should be deposit $10' > user.bank.deposit(10) > user.bank.deposit.saving.should == 10 > user.deposit_record.should == #something. > end > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users cheers, Matt http://blog.mattwynne.net +44(0)7974 430184 From dlidstrom at gmail.com Fri Aug 27 16:12:27 2010 From: dlidstrom at gmail.com (=?ISO-8859-1?Q?Daniel_Lidstr=F6m?=) Date: Fri, 27 Aug 2010 13:12:27 -0700 (PDT) Subject: [rspec-users] stack level too deep Message-ID: <6ae2a13c-9feb-4a63-8f87-4bb7f4950e23@m1g2000yqo.googlegroups.com> Hello, I am trying to run my first integration tests of my rails 3 application. All tests fail with an error "stack level too deep". The tests are intended to verify the link routes and look like this: daniel at ubuntu/home/daniel/programming/rails_projects/sample_app$ cat spec/requests/layout_links_spec.rb require 'spec_helper' describe "LayoutLinks" do it "should have a Home page at '/'" do get '/' response.should have_selector('title', :content => "Home") end it "should have a Contact page at '/contact'" do get '/contact' response.should have_selector('title', :content => "Contact") end it "should have an About page at '/about'" do get '/about' response.should have_selector('title', :content => "About") end it "should have a Help page at '/help'" do get '/help' response.should have_selector('title', :content => "Help") end end My routes.rb looks like this: daniel at ubuntu/home/daniel/programming/rails_projects/sample_app$ cat config/routes.rb SampleApp::Application.routes.draw do get "pages/home" get "pages/contact" get "pages/about" get "pages/help" match '/about', :to => 'pages#about' match '/contact', :to => 'pages#contact' match '/help', :to => 'pages#help' match '/signup', :to => 'pages#signup' match '/signin', :to => 'pages#signin' end Now when I try to run the tests I get a stack level too deep error for each one of them. Here's the output from "rspec -b spec/ requests" (last test included, others look the same): 4) LayoutLinks should have a Help page at '/help' Failure/Error: response.should have_selector('title', :content => "Help") stack level too deep . . . . # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/ adapters/rack.rb:26:in `response' # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/core/ methods.rb:29:in `response' # /usr/lib/ruby/gems/1.8/gems/rspec-rails-2.0.0.beta.19/lib/rspec/ rails/example/request_example_group.rb:34:in `last_response' # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/ adapters/rack.rb:26:in `response' # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/core/ methods.rb:29:in `response' # /usr/lib/ruby/gems/1.8/gems/rspec-rails-2.0.0.beta.19/lib/rspec/ rails/example/request_example_group.rb:34:in `last_response' # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/ adapters/rack.rb:26:in `response' # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/core/ methods.rb:29:in `response' # /usr/lib/ruby/gems/1.8/gems/rspec-rails-2.0.0.beta.19/lib/rspec/ rails/example/request_example_group.rb:34:in `last_response' # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/ adapters/rack.rb:26:in `response' # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/core/ methods.rb:29:in `response' # /usr/lib/ruby/gems/1.8/gems/rspec-rails-2.0.0.beta.19/lib/rspec/ rails/example/request_example_group.rb:34:in `last_response' # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/ adapters/rack.rb:26:in `response' # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/core/ methods.rb:29:in `response' # /usr/lib/ruby/gems/1.8/gems/rspec-rails-2.0.0.beta.19/lib/rspec/ rails/example/request_example_group.rb:34:in `last_response' # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/ adapters/rack.rb:26:in `response' # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/core/ methods.rb:29:in `response' # /usr/lib/ruby/gems/1.8/gems/rspec-rails-2.0.0.beta.19/lib/rspec/ rails/example/request_example_group.rb:34:in `last_response' # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/ adapters/rack.rb:26:in `response' # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/core/ methods.rb:29:in `response' # /usr/lib/ruby/gems/1.8/gems/rspec-rails-2.0.0.beta.19/lib/rspec/ rails/example/request_example_group.rb:34:in `last_response' # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/ adapters/rack.rb:26:in `response' # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/core/ methods.rb:29:in `response' # /usr/lib/ruby/gems/1.8/gems/rspec-rails-2.0.0.beta.19/lib/rspec/ rails/example/request_example_group.rb:34:in `last_response' # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/ adapters/rack.rb:26:in `response' # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/core/ methods.rb:29:in `response' # /usr/lib/ruby/gems/1.8/gems/rspec-rails-2.0.0.beta.19/lib/rspec/ rails/example/request_example_group.rb:34:in `last_response' # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/ adapters/rack.rb:26:in `response' # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/core/ methods.rb:29:in `response' # ./spec/requests/layout_links_spec.rb:22 # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ core/example.rb:52:in `instance_eval' # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ core/example.rb:52 # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ core/example.rb:86:in `call' # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ core/example.rb:86:in `with_around_hooks' # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ core/example.rb:48 # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ core/example.rb:80:in `call' # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ core/example.rb:80:in `with_pending_capture' # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ core/example.rb:79:in `catch' # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ core/example.rb:79:in `with_pending_capture' # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ core/example.rb:47:in `run' # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ core/example_group.rb:222:in `run_examples' # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ core/example_group.rb:219:in `map' # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ core/example_group.rb:219:in `run_examples' # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ core/example_group.rb:210:in `run' # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ core/command_line.rb:42:in `run_examples' # /home/daniel/.gem/ruby/1.8/gems/activesupport-3.0.0.rc/lib/ active_support/dependencies.rb:219:in `inject' # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ core/command_line.rb:42:in `each' # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ core/command_line.rb:42:in `inject' # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ core/command_line.rb:42:in `run_examples' # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ core/command_line.rb:25:in `run' # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ core/formatters/base_formatter.rb:37:in `report' # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ core/formatters/base_formatter.rb:156:in `sync_output' # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ core/formatters/base_formatter.rb:34:in `report' # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ core/command_line.rb:22:in `run' # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ core/runner.rb:46:in `run_in_process' # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ core/runner.rb:37:in `run' # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ core/runner.rb:10 # /usr/bin/rspec:19 daniel at ubuntu/home/daniel/programming/rails_projects/sample_app$ My Gemfile looks like this: daniel at ubuntu/home/daniel/programming/rails_projects/sample_app$ cat Gemfile source 'http://rubygems.org' gem 'rails', '3.0.0.rc' # Bundle edge Rails instead: # gem 'rails', :git => 'git://github.com/rails/rails.git' gem 'sqlite3-ruby', :require => 'sqlite3' group :development, :test do gem 'rspec-rails', '>= 2.0.0.beta.19' end Any ideas what is going on? I am using Ubuntu 10.04 x86_64. Regards, Daniel Lidstr?m Stockholm, Sweden From jko170 at gmail.com Fri Aug 27 17:47:38 2010 From: jko170 at gmail.com (Justin Ko) Date: Fri, 27 Aug 2010 14:47:38 -0700 (PDT) Subject: [rspec-users] stack level too deep In-Reply-To: <6ae2a13c-9feb-4a63-8f87-4bb7f4950e23@m1g2000yqo.googlegroups.com> References: <6ae2a13c-9feb-4a63-8f87-4bb7f4950e23@m1g2000yqo.googlegroups.com> Message-ID: <725b9d11-f181-410f-b825-daa383a3bf96@j18g2000yqd.googlegroups.com> One thing I notice is you have "get '/'" yet you don't have a root route. You can define a root route like so: root :to => "pages#home" Also, you can run your requests by doing "rake spec:requests" On Aug 27, 4:12?pm, Daniel Lidstr?m wrote: > Hello, > > I am trying to run my first integration tests of my rails 3 > application. All tests fail with an error "stack level too deep". The > tests are intended to verify the link routes and look like this: > > daniel at ubuntu/home/daniel/programming/rails_projects/sample_app$ cat > spec/requests/layout_links_spec.rb > require 'spec_helper' > > describe "LayoutLinks" do > > ? it "should have a Home page at '/'" do > ? ? get '/' > ? ? response.should have_selector('title', :content => "Home") > ? end > > ? it "should have a Contact page at '/contact'" do > ? ? get '/contact' > ? ? response.should have_selector('title', :content => "Contact") > ? end > > ? it "should have an About page at '/about'" do > ? ? get '/about' > ? ? response.should have_selector('title', :content => "About") > ? end > > ? it "should have a Help page at '/help'" do > ? ? get '/help' > ? ? response.should have_selector('title', :content => "Help") > ? end > > end > > My routes.rb looks like this: > > daniel at ubuntu/home/daniel/programming/rails_projects/sample_app$ cat > config/routes.rb > SampleApp::Application.routes.draw do > ? get "pages/home" > > ? get "pages/contact" > > ? get "pages/about" > > ? get "pages/help" > > ? match '/about', :to => 'pages#about' > > ? match '/contact', :to => 'pages#contact' > > ? match '/help', :to => 'pages#help' > > ? match '/signup', :to => 'pages#signup' > > ? match '/signin', :to => 'pages#signin' > end > > Now when I try to run the tests I get a stack level too deep error for > each one of them. Here's the output from "rspec -b spec/ > requests" (last test included, others look the same): > > 4) LayoutLinks should have a Help page at '/help' > ? ? Failure/Error: response.should have_selector('title', :content => > "Help") > ? ? stack level too deep > ? ? ? ? . > ? ? ? ? . > ? ? ? ? . > ? ? ? ? . > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/ > adapters/rack.rb:26:in `response' > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/core/ > methods.rb:29:in `response' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-rails-2.0.0.beta.19/lib/rspec/ > rails/example/request_example_group.rb:34:in `last_response' > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/ > adapters/rack.rb:26:in `response' > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/core/ > methods.rb:29:in `response' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-rails-2.0.0.beta.19/lib/rspec/ > rails/example/request_example_group.rb:34:in `last_response' > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/ > adapters/rack.rb:26:in `response' > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/core/ > methods.rb:29:in `response' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-rails-2.0.0.beta.19/lib/rspec/ > rails/example/request_example_group.rb:34:in `last_response' > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/ > adapters/rack.rb:26:in `response' > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/core/ > methods.rb:29:in `response' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-rails-2.0.0.beta.19/lib/rspec/ > rails/example/request_example_group.rb:34:in `last_response' > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/ > adapters/rack.rb:26:in `response' > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/core/ > methods.rb:29:in `response' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-rails-2.0.0.beta.19/lib/rspec/ > rails/example/request_example_group.rb:34:in `last_response' > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/ > adapters/rack.rb:26:in `response' > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/core/ > methods.rb:29:in `response' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-rails-2.0.0.beta.19/lib/rspec/ > rails/example/request_example_group.rb:34:in `last_response' > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/ > adapters/rack.rb:26:in `response' > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/core/ > methods.rb:29:in `response' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-rails-2.0.0.beta.19/lib/rspec/ > rails/example/request_example_group.rb:34:in `last_response' > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/ > adapters/rack.rb:26:in `response' > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/core/ > methods.rb:29:in `response' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-rails-2.0.0.beta.19/lib/rspec/ > rails/example/request_example_group.rb:34:in `last_response' > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/ > adapters/rack.rb:26:in `response' > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/core/ > methods.rb:29:in `response' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-rails-2.0.0.beta.19/lib/rspec/ > rails/example/request_example_group.rb:34:in `last_response' > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/ > adapters/rack.rb:26:in `response' > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/core/ > methods.rb:29:in `response' > ? ? # ./spec/requests/layout_links_spec.rb:22 > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/example.rb:52:in `instance_eval' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/example.rb:52 > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/example.rb:86:in `call' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/example.rb:86:in `with_around_hooks' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/example.rb:48 > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/example.rb:80:in `call' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/example.rb:80:in `with_pending_capture' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/example.rb:79:in `catch' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/example.rb:79:in `with_pending_capture' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/example.rb:47:in `run' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/example_group.rb:222:in `run_examples' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/example_group.rb:219:in `map' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/example_group.rb:219:in `run_examples' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/example_group.rb:210:in `run' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/command_line.rb:42:in `run_examples' > ? ? # /home/daniel/.gem/ruby/1.8/gems/activesupport-3.0.0.rc/lib/ > active_support/dependencies.rb:219:in `inject' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/command_line.rb:42:in `each' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/command_line.rb:42:in `inject' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/command_line.rb:42:in `run_examples' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/command_line.rb:25:in `run' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/formatters/base_formatter.rb:37:in `report' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/formatters/base_formatter.rb:156:in `sync_output' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/formatters/base_formatter.rb:34:in `report' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/command_line.rb:22:in `run' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/runner.rb:46:in `run_in_process' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/runner.rb:37:in `run' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/runner.rb:10 > ? ? # /usr/bin/rspec:19 > > daniel at ubuntu/home/daniel/programming/rails_projects/sample_app$ > > My Gemfile looks like this: > > daniel at ubuntu/home/daniel/programming/rails_projects/sample_app$ cat > Gemfile > source 'http://rubygems.org' > > gem 'rails', '3.0.0.rc' > > # Bundle edge Rails instead: > # gem 'rails', :git => 'git://github.com/rails/rails.git' > > gem 'sqlite3-ruby', :require => 'sqlite3' > > group :development, :test do > ? gem 'rspec-rails', '>= 2.0.0.beta.19' > end > > Any ideas what is going on? I am using Ubuntu 10.04 x86_64. > > Regards, > > Daniel Lidstr?m > Stockholm, Sweden > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users From jko170 at gmail.com Fri Aug 27 02:36:47 2010 From: jko170 at gmail.com (Justin Ko) Date: Thu, 26 Aug 2010 23:36:47 -0700 (PDT) Subject: [rspec-users] there should be one test or two? In-Reply-To: References: Message-ID: <15683a91-a02b-4db9-853c-9ff13cb3c4b5@i31g2000yqm.googlegroups.com> The "best practice" in your situation is to have two specs like so: describe "#deposit" do it 'adds $10 to a savings account' do user.bank.deposit(10) user.bank.deposit.saving.should == 10 end it 'creates a deposit record' do user.bank.deposit(10) user.deposit_record.should == #something. end end There are two downsides to having multiple expectations (should's) in one example/spec: 1.) If the first expectation fails, the second one will not run. false.should be_true # fails false.should be_false # never runs 2.) It is much more simple for the description of the example/spec to specify one expected behaviour. If you did something like this: it "deposits $10 to a savings account and adds a new record" You would have to remember that you're checking for TWO behaviours, which is not as clear and direct as one. Hope this helps. On Aug 27, 1:43?am, Zhenning Guan wrote: > in real world, when user deposit money into their bank, bank have money > and can check deposit record. so what would it be in rspec? > > it 'should be deposit $10' > ? user.bank.deposit(10) > ? user.bank.deposit.saving.should == 10 > end > > about test , should be deposit $10 is clear? maybe 'should deposit $10 > success'? > > and when deposit, we should have a deposit record. added another test? > > it 'should be a deposit record when deposit $10' > ? user.bank.deposit(10) > ? user.deposit_record.should == #something. > end > > or just mixed it in one test? > > it 'should be deposit $10' > ? user.bank.deposit(10) > ? user.bank.deposit.saving.should == 10 > ? user.deposit_record.should == #something. > end > -- > Posted viahttp://www.ruby-forum.com/. > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users From jko170 at gmail.com Fri Aug 27 02:48:52 2010 From: jko170 at gmail.com (Justin Ko) Date: Thu, 26 Aug 2010 23:48:52 -0700 (PDT) Subject: [rspec-users] Controller spec with devise. In-Reply-To: References: Message-ID: <80d12572-44c2-4efa-9890-a8f866336b2a@k10g2000yqa.googlegroups.com> This is how I do it: before { sign_in(user_record) } describe "#index" do before do controller.current_user.stub(:orders) { ... } end it "..." do get :index end end Hope that helps. On Aug 24, 7:51?pm, Titinux wrote: > Hello, > > I'm new in using RSpec and I can't figured out to spec this controller > action. > > class OrdersController < ApplicationController > ? before_filter :authenticate_user! > > ? def index > ? ? respond_with(@orders = current_user.orders) > ? end > end > > When I want to spec this "@assets = Asset.all" I use "Asset.stub(:all) > { [mock_asset] }" as I read in the RSpec book but with > "current_user.orders" I don't know how to do. > > NB: I'm using Rails 3.0.0.rc2 and RSpec 2.0.0.beta.20 > > Thanks in advance. > J?r?mie Horhant > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users From jko170 at gmail.com Fri Aug 27 03:00:24 2010 From: jko170 at gmail.com (Justin Ko) Date: Fri, 27 Aug 2010 00:00:24 -0700 (PDT) Subject: [rspec-users] Default format for all requests in a spec In-Reply-To: References: Message-ID: Well, you could setup a default parameter hash: describe MyController do let(:params) { {:format => 'js'} } describe '#show' do it '...' do get :show, params.merge(:id => 1) end end end You could also take it another level: describe MyController do let(:params) { {:format => 'js'} } describe '#show' do before { params.merge(:id => 1) } it '...' do get :show, params.merge(:another_param => 'yep') end end end On Aug 26, 9:12?am, Maur?cio Linhares wrote: > Hi guys, > > Is there a way to define a default parameter for all requests made in a spec? > > I have a spec where I want all requests to be made with the "js" > format but I find it rather annoying to type a ":format => 'js'" on > every get/post/put/delete. Is there any other way to do this? > > - > Maur?cio Linhareshttp://codeshooter.wordpress.com/|http://twitter.com/mauriciojr > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users From dchelimsky at gmail.com Fri Aug 27 18:12:16 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 27 Aug 2010 17:12:16 -0500 Subject: [rspec-users] there should be one test or two? In-Reply-To: <15683a91-a02b-4db9-853c-9ff13cb3c4b5@i31g2000yqm.googlegroups.com> References: <15683a91-a02b-4db9-853c-9ff13cb3c4b5@i31g2000yqm.googlegroups.com> Message-ID: <7B3003CE-FC3C-4200-877D-2F36A50E5E50@gmail.com> On Aug 27, 2010, at 1:36 AM, Justin Ko wrote: > The "best practice" in your situation is to have two specs like so: > > describe "#deposit" do > it 'adds $10 to a savings account' do > user.bank.deposit(10) > user.bank.deposit.saving.should == 10 > end > > it 'creates a deposit record' do > user.bank.deposit(10) > user.deposit_record.should == #something. > end > end > > There are two downsides to having multiple expectations (should's) in > one example/spec: > > 1.) If the first expectation fails, the second one will not run. > false.should be_true # fails > false.should be_false # never runs > > 2.) It is much more simple for the description of the example/spec to > specify one expected behaviour. If you did something like this: > it "deposits $10 to a savings account and adds a new record" > You would have to remember that you're checking for TWO > behaviours, which is not as clear and direct as one. There's also an upside to separating the examples (it's not all avoiding negatives), which is that you express the spec more accurately. Consider the output (slightly rephrased): Account #deposit increases the balance creates a deposit record Now it _looks like_ a spec. HTH, David > > Hope this helps. > > On Aug 27, 1:43 am, Zhenning Guan wrote: >> in real world, when user deposit money into their bank, bank have money >> and can check deposit record. so what would it be in rspec? >> >> it 'should be deposit $10' >> user.bank.deposit(10) >> user.bank.deposit.saving.should == 10 >> end >> >> about test , should be deposit $10 is clear? maybe 'should deposit $10 >> success'? >> >> and when deposit, we should have a deposit record. added another test? >> >> it 'should be a deposit record when deposit $10' >> user.bank.deposit(10) >> user.deposit_record.should == #something. >> end >> >> or just mixed it in one test? >> >> it 'should be deposit $10' >> user.bank.deposit(10) >> user.bank.deposit.saving.should == 10 >> user.deposit_record.should == #something. >> end >> -- >> Posted viahttp://www.ruby-forum.com/. >> _______________________________________________ >> rspec-users mailing list >> rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users From myron.marston at gmail.com Fri Aug 27 19:59:24 2010 From: myron.marston at gmail.com (Myron Marston) Date: Fri, 27 Aug 2010 16:59:24 -0700 (PDT) Subject: [rspec-users] there should be one test or two? In-Reply-To: <7B3003CE-FC3C-4200-877D-2F36A50E5E50@gmail.com> References: <15683a91-a02b-4db9-853c-9ff13cb3c4b5@i31g2000yqm.googlegroups.com> <7B3003CE-FC3C-4200-877D-2F36A50E5E50@gmail.com> Message-ID: <9ee7ca8c-75a0-4299-a829-9f439ea611a2@h40g2000pro.googlegroups.com> > One assertion per test [1] is a good rule of thumb, but don't get too hung up about it. To rephrase this slightly, you should test one behavior per spec, and having multiple assertions or expectations in the same test is a good sign that you may be testing multiple behaviors. From myron.marston at gmail.com Fri Aug 27 20:18:08 2010 From: myron.marston at gmail.com (Myron Marston) Date: Fri, 27 Aug 2010 17:18:08 -0700 (PDT) Subject: [rspec-users] respond_to? check in rspec-mocks Message-ID: <29e21302-41f8-44b9-b43f-97b3873aadb9@h17g2000pri.googlegroups.com> One of the primary dangers of using mocks is that your unit tests may be testing against an interface that is different from that of your production objects. You may simply have misspelled the method (e.g. object.should_receive(:methd_name) rather than method_name), or you may have changed the interface of your production object without updating your tests. Obviously, you should have some integration coverage that will catch these kinds of errors (and I do), but it's nice when they're caught by your unit tests since they're so much faster than integration tests. I've been using a pattern to help with this for a while: it "safely mocks a method" do object.should respond_to(:foo) object.should_receive(:foo).and_return(:bar) object.do_something_that_calls_foo end Basically, I add a respond_to? check before mocking or stubbing a concrete object (obviously, I don't do this for a pure mock object). If/when I rename the mocked method, I'll get a test failure. I think it'd be nice to add this to rspec-mocks itself. A few additional thoughts about this potential feature: * This would only apply when you're mocking/stubbing concrete objects; on a pure mock or stub it wouldn't do the check. * Should this print a warning or raise an error so the test fails? * Should it be configurable? I could see some people not wanting this feature, particularly if you're strictly following the outside-in BDD process where the specs on the outer layers (say, a controller in a rails app) mock methods that have not yet been defined on the inner layers (say, a model in a rails app). * This feature could potentially take things a step further and when you specify mock arguments using `with`, it could check the arity of the method and be sure that the method accepts that number of arguments. What do people think about this idea? Myron From jko170 at gmail.com Fri Aug 27 20:24:25 2010 From: jko170 at gmail.com (Justin Ko) Date: Fri, 27 Aug 2010 17:24:25 -0700 (PDT) Subject: [rspec-users] respond_to? check in rspec-mocks In-Reply-To: <29e21302-41f8-44b9-b43f-97b3873aadb9@h17g2000pri.googlegroups.com> References: <29e21302-41f8-44b9-b43f-97b3873aadb9@h17g2000pri.googlegroups.com> Message-ID: On Aug 27, 8:18?pm, Myron Marston wrote: > One of the primary dangers of using mocks is that your unit tests may > be testing against an interface that is different from that of your > production objects. ?You may simply have misspelled the method (e.g. > object.should_receive(:methd_name) rather than method_name), or you > may have changed the interface of your production object without > updating your tests. > > Obviously, you should have some integration coverage that will catch > these kinds of errors (and I do), but it's nice when they're caught by > your unit tests since they're so much faster than integration tests. > I've been using a pattern to help with this for a while: > > it "safely mocks a method" do > ? object.should respond_to(:foo) > ? object.should_receive(:foo).and_return(:bar) > ? object.do_something_that_calls_foo > end > > Basically, I add a respond_to? check before mocking or stubbing a > concrete object (obviously, I don't do this for a pure mock object). > If/when I rename the mocked method, I'll get a test failure. ?I think > it'd be nice to add this to rspec-mocks itself. ?A few additional > thoughts about this potential feature: > > * This would only apply when you're mocking/stubbing concrete objects; > on a pure mock or stub it wouldn't do the check. > * Should this print a warning or raise an error so the test fails? > * Should it be configurable? ?I could see some people not wanting this > feature, particularly if you're strictly following the outside-in BDD > process where the specs on the outer layers (say, a controller in a > rails app) mock methods that have not yet been defined on the inner > layers (say, a model in a rails app). > * This feature could potentially take things a step further and when > you specify mock arguments using `with`, it could check the arity of > the method and be sure that the method accepts that number of > arguments. > > What do people think about this idea? > > Myron > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users What defines a "concrete object"? From jko170 at gmail.com Fri Aug 27 20:42:32 2010 From: jko170 at gmail.com (Justin Ko) Date: Fri, 27 Aug 2010 17:42:32 -0700 (PDT) Subject: [rspec-users] respond_to? check in rspec-mocks In-Reply-To: References: <29e21302-41f8-44b9-b43f-97b3873aadb9@h17g2000pri.googlegroups.com> Message-ID: <005a080a-58a3-4831-a1ad-5e87874b4c74@d8g2000yqf.googlegroups.com> On Aug 27, 8:24?pm, Justin Ko wrote: > On Aug 27, 8:18?pm, Myron Marston wrote: > > > > > > > One of the primary dangers of using mocks is that your unit tests may > > be testing against an interface that is different from that of your > > production objects. ?You may simply have misspelled the method (e.g. > > object.should_receive(:methd_name) rather than method_name), or you > > may have changed the interface of your production object without > > updating your tests. > > > Obviously, you should have some integration coverage that will catch > > these kinds of errors (and I do), but it's nice when they're caught by > > your unit tests since they're so much faster than integration tests. > > I've been using a pattern to help with this for a while: > > > it "safely mocks a method" do > > ? object.should respond_to(:foo) > > ? object.should_receive(:foo).and_return(:bar) > > ? object.do_something_that_calls_foo > > end > > > Basically, I add a respond_to? check before mocking or stubbing a > > concrete object (obviously, I don't do this for a pure mock object). > > If/when I rename the mocked method, I'll get a test failure. ?I think > > it'd be nice to add this to rspec-mocks itself. ?A few additional > > thoughts about this potential feature: > > > * This would only apply when you're mocking/stubbing concrete objects; > > on a pure mock or stub it wouldn't do the check. > > * Should this print a warning or raise an error so the test fails? > > * Should it be configurable? ?I could see some people not wanting this > > feature, particularly if you're strictly following the outside-in BDD > > process where the specs on the outer layers (say, a controller in a > > rails app) mock methods that have not yet been defined on the inner > > layers (say, a model in a rails app). > > * This feature could potentially take things a step further and when > > you specify mock arguments using `with`, it could check the arity of > > the method and be sure that the method accepts that number of > > arguments. > > > What do people think about this idea? > > > Myron > > _______________________________________________ > > rspec-users mailing list > > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users > > What defines a "concrete object"? > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users Anything that is not an RSpec stub object? From jko170 at gmail.com Fri Aug 27 20:44:44 2010 From: jko170 at gmail.com (Justin Ko) Date: Fri, 27 Aug 2010 17:44:44 -0700 (PDT) Subject: [rspec-users] stack level too deep In-Reply-To: <6ae2a13c-9feb-4a63-8f87-4bb7f4950e23@m1g2000yqo.googlegroups.com> References: <6ae2a13c-9feb-4a63-8f87-4bb7f4950e23@m1g2000yqo.googlegroups.com> Message-ID: On Aug 27, 4:12?pm, Daniel Lidstr?m wrote: > Hello, > > I am trying to run my first integration tests of my rails 3 > application. All tests fail with an error "stack level too deep". The > tests are intended to verify the link routes and look like this: > > daniel at ubuntu/home/daniel/programming/rails_projects/sample_app$ cat > spec/requests/layout_links_spec.rb > require 'spec_helper' > > describe "LayoutLinks" do > > ? it "should have a Home page at '/'" do > ? ? get '/' > ? ? response.should have_selector('title', :content => "Home") > ? end > > ? it "should have a Contact page at '/contact'" do > ? ? get '/contact' > ? ? response.should have_selector('title', :content => "Contact") > ? end > > ? it "should have an About page at '/about'" do > ? ? get '/about' > ? ? response.should have_selector('title', :content => "About") > ? end > > ? it "should have a Help page at '/help'" do > ? ? get '/help' > ? ? response.should have_selector('title', :content => "Help") > ? end > > end > > My routes.rb looks like this: > > daniel at ubuntu/home/daniel/programming/rails_projects/sample_app$ cat > config/routes.rb > SampleApp::Application.routes.draw do > ? get "pages/home" > > ? get "pages/contact" > > ? get "pages/about" > > ? get "pages/help" > > ? match '/about', :to => 'pages#about' > > ? match '/contact', :to => 'pages#contact' > > ? match '/help', :to => 'pages#help' > > ? match '/signup', :to => 'pages#signup' > > ? match '/signin', :to => 'pages#signin' > end > > Now when I try to run the tests I get a stack level too deep error for > each one of them. Here's the output from "rspec -b spec/ > requests" (last test included, others look the same): > > 4) LayoutLinks should have a Help page at '/help' > ? ? Failure/Error: response.should have_selector('title', :content => > "Help") > ? ? stack level too deep > ? ? ? ? . > ? ? ? ? . > ? ? ? ? . > ? ? ? ? . > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/ > adapters/rack.rb:26:in `response' > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/core/ > methods.rb:29:in `response' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-rails-2.0.0.beta.19/lib/rspec/ > rails/example/request_example_group.rb:34:in `last_response' > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/ > adapters/rack.rb:26:in `response' > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/core/ > methods.rb:29:in `response' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-rails-2.0.0.beta.19/lib/rspec/ > rails/example/request_example_group.rb:34:in `last_response' > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/ > adapters/rack.rb:26:in `response' > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/core/ > methods.rb:29:in `response' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-rails-2.0.0.beta.19/lib/rspec/ > rails/example/request_example_group.rb:34:in `last_response' > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/ > adapters/rack.rb:26:in `response' > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/core/ > methods.rb:29:in `response' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-rails-2.0.0.beta.19/lib/rspec/ > rails/example/request_example_group.rb:34:in `last_response' > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/ > adapters/rack.rb:26:in `response' > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/core/ > methods.rb:29:in `response' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-rails-2.0.0.beta.19/lib/rspec/ > rails/example/request_example_group.rb:34:in `last_response' > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/ > adapters/rack.rb:26:in `response' > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/core/ > methods.rb:29:in `response' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-rails-2.0.0.beta.19/lib/rspec/ > rails/example/request_example_group.rb:34:in `last_response' > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/ > adapters/rack.rb:26:in `response' > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/core/ > methods.rb:29:in `response' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-rails-2.0.0.beta.19/lib/rspec/ > rails/example/request_example_group.rb:34:in `last_response' > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/ > adapters/rack.rb:26:in `response' > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/core/ > methods.rb:29:in `response' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-rails-2.0.0.beta.19/lib/rspec/ > rails/example/request_example_group.rb:34:in `last_response' > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/ > adapters/rack.rb:26:in `response' > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/core/ > methods.rb:29:in `response' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-rails-2.0.0.beta.19/lib/rspec/ > rails/example/request_example_group.rb:34:in `last_response' > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/ > adapters/rack.rb:26:in `response' > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/core/ > methods.rb:29:in `response' > ? ? # ./spec/requests/layout_links_spec.rb:22 > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/example.rb:52:in `instance_eval' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/example.rb:52 > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/example.rb:86:in `call' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/example.rb:86:in `with_around_hooks' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/example.rb:48 > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/example.rb:80:in `call' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/example.rb:80:in `with_pending_capture' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/example.rb:79:in `catch' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/example.rb:79:in `with_pending_capture' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/example.rb:47:in `run' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/example_group.rb:222:in `run_examples' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/example_group.rb:219:in `map' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/example_group.rb:219:in `run_examples' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/example_group.rb:210:in `run' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/command_line.rb:42:in `run_examples' > ? ? # /home/daniel/.gem/ruby/1.8/gems/activesupport-3.0.0.rc/lib/ > active_support/dependencies.rb:219:in `inject' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/command_line.rb:42:in `each' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/command_line.rb:42:in `inject' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/command_line.rb:42:in `run_examples' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/command_line.rb:25:in `run' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/formatters/base_formatter.rb:37:in `report' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/formatters/base_formatter.rb:156:in `sync_output' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/formatters/base_formatter.rb:34:in `report' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/command_line.rb:22:in `run' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/runner.rb:46:in `run_in_process' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/runner.rb:37:in `run' > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > core/runner.rb:10 > ? ? # /usr/bin/rspec:19 > > daniel at ubuntu/home/daniel/programming/rails_projects/sample_app$ > > My Gemfile looks like this: > > daniel at ubuntu/home/daniel/programming/rails_projects/sample_app$ cat > Gemfile > source 'http://rubygems.org' > > gem 'rails', '3.0.0.rc' > > # Bundle edge Rails instead: > # gem 'rails', :git => 'git://github.com/rails/rails.git' > > gem 'sqlite3-ruby', :require => 'sqlite3' > > group :development, :test do > ? gem 'rspec-rails', '>= 2.0.0.beta.19' > end > > Any ideas what is going on? I am using Ubuntu 10.04 x86_64. > > Regards, > > Daniel Lidstr?m > Stockholm, Sweden > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users I can reproduce this error with webrat version 0.7.2.beta.1 From myron.marston at gmail.com Fri Aug 27 21:07:36 2010 From: myron.marston at gmail.com (Myron Marston) Date: Fri, 27 Aug 2010 18:07:36 -0700 (PDT) Subject: [rspec-users] respond_to? check in rspec-mocks In-Reply-To: <005a080a-58a3-4831-a1ad-5e87874b4c74@d8g2000yqf.googlegroups.com> References: <29e21302-41f8-44b9-b43f-97b3873aadb9@h17g2000pri.googlegroups.com> <005a080a-58a3-4831-a1ad-5e87874b4c74@d8g2000yqf.googlegroups.com> Message-ID: <4c1e1d8e-58c2-49f3-a940-f29dd925d523@x18g2000pro.googlegroups.com> > What defines a "concrete object"? > Anything that is not an RSpec stub object? Yep, that's how I'm using the term. It doesn't make sense to do a respond_to? check on a pure mock or stub object, since it doesn't initially have a defined interface (outside of the interface of Object). From jko170 at gmail.com Fri Aug 27 22:13:45 2010 From: jko170 at gmail.com (Justin Ko) Date: Fri, 27 Aug 2010 19:13:45 -0700 (PDT) Subject: [rspec-users] stack level too deep In-Reply-To: References: <6ae2a13c-9feb-4a63-8f87-4bb7f4950e23@m1g2000yqo.googlegroups.com> Message-ID: <9d740d4a-2ab8-490c-a56c-391ceda29639@z10g2000yqb.googlegroups.com> On Aug 27, 8:44?pm, Justin Ko wrote: > On Aug 27, 4:12?pm, Daniel Lidstr?m wrote: > > > > > > > Hello, > > > I am trying to run my first integration tests of my rails 3 > > application. All tests fail with an error "stack level too deep". The > > tests are intended to verify the link routes and look like this: > > > daniel at ubuntu/home/daniel/programming/rails_projects/sample_app$ cat > > spec/requests/layout_links_spec.rb > > require 'spec_helper' > > > describe "LayoutLinks" do > > > ? it "should have a Home page at '/'" do > > ? ? get '/' > > ? ? response.should have_selector('title', :content => "Home") > > ? end > > > ? it "should have a Contact page at '/contact'" do > > ? ? get '/contact' > > ? ? response.should have_selector('title', :content => "Contact") > > ? end > > > ? it "should have an About page at '/about'" do > > ? ? get '/about' > > ? ? response.should have_selector('title', :content => "About") > > ? end > > > ? it "should have a Help page at '/help'" do > > ? ? get '/help' > > ? ? response.should have_selector('title', :content => "Help") > > ? end > > > end > > > My routes.rb looks like this: > > > daniel at ubuntu/home/daniel/programming/rails_projects/sample_app$ cat > > config/routes.rb > > SampleApp::Application.routes.draw do > > ? get "pages/home" > > > ? get "pages/contact" > > > ? get "pages/about" > > > ? get "pages/help" > > > ? match '/about', :to => 'pages#about' > > > ? match '/contact', :to => 'pages#contact' > > > ? match '/help', :to => 'pages#help' > > > ? match '/signup', :to => 'pages#signup' > > > ? match '/signin', :to => 'pages#signin' > > end > > > Now when I try to run the tests I get a stack level too deep error for > > each one of them. Here's the output from "rspec -b spec/ > > requests" (last test included, others look the same): > > > 4) LayoutLinks should have a Help page at '/help' > > ? ? Failure/Error: response.should have_selector('title', :content => > > "Help") > > ? ? stack level too deep > > ? ? ? ? . > > ? ? ? ? . > > ? ? ? ? . > > ? ? ? ? . > > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/ > > adapters/rack.rb:26:in `response' > > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/core/ > > methods.rb:29:in `response' > > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-rails-2.0.0.beta.19/lib/rspec/ > > rails/example/request_example_group.rb:34:in `last_response' > > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/ > > adapters/rack.rb:26:in `response' > > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/core/ > > methods.rb:29:in `response' > > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-rails-2.0.0.beta.19/lib/rspec/ > > rails/example/request_example_group.rb:34:in `last_response' > > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/ > > adapters/rack.rb:26:in `response' > > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/core/ > > methods.rb:29:in `response' > > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-rails-2.0.0.beta.19/lib/rspec/ > > rails/example/request_example_group.rb:34:in `last_response' > > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/ > > adapters/rack.rb:26:in `response' > > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/core/ > > methods.rb:29:in `response' > > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-rails-2.0.0.beta.19/lib/rspec/ > > rails/example/request_example_group.rb:34:in `last_response' > > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/ > > adapters/rack.rb:26:in `response' > > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/core/ > > methods.rb:29:in `response' > > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-rails-2.0.0.beta.19/lib/rspec/ > > rails/example/request_example_group.rb:34:in `last_response' > > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/ > > adapters/rack.rb:26:in `response' > > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/core/ > > methods.rb:29:in `response' > > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-rails-2.0.0.beta.19/lib/rspec/ > > rails/example/request_example_group.rb:34:in `last_response' > > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/ > > adapters/rack.rb:26:in `response' > > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/core/ > > methods.rb:29:in `response' > > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-rails-2.0.0.beta.19/lib/rspec/ > > rails/example/request_example_group.rb:34:in `last_response' > > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/ > > adapters/rack.rb:26:in `response' > > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/core/ > > methods.rb:29:in `response' > > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-rails-2.0.0.beta.19/lib/rspec/ > > rails/example/request_example_group.rb:34:in `last_response' > > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/ > > adapters/rack.rb:26:in `response' > > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/core/ > > methods.rb:29:in `response' > > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-rails-2.0.0.beta.19/lib/rspec/ > > rails/example/request_example_group.rb:34:in `last_response' > > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/ > > adapters/rack.rb:26:in `response' > > ? ? # /usr/lib/ruby/gems/1.8/gems/webrat-0.7.2.beta.1/lib/webrat/core/ > > methods.rb:29:in `response' > > ? ? # ./spec/requests/layout_links_spec.rb:22 > > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > > core/example.rb:52:in `instance_eval' > > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > > core/example.rb:52 > > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > > core/example.rb:86:in `call' > > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > > core/example.rb:86:in `with_around_hooks' > > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > > core/example.rb:48 > > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > > core/example.rb:80:in `call' > > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > > core/example.rb:80:in `with_pending_capture' > > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > > core/example.rb:79:in `catch' > > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > > core/example.rb:79:in `with_pending_capture' > > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > > core/example.rb:47:in `run' > > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > > core/example_group.rb:222:in `run_examples' > > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > > core/example_group.rb:219:in `map' > > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > > core/example_group.rb:219:in `run_examples' > > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > > core/example_group.rb:210:in `run' > > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > > core/command_line.rb:42:in `run_examples' > > ? ? # /home/daniel/.gem/ruby/1.8/gems/activesupport-3.0.0.rc/lib/ > > active_support/dependencies.rb:219:in `inject' > > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > > core/command_line.rb:42:in `each' > > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > > core/command_line.rb:42:in `inject' > > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > > core/command_line.rb:42:in `run_examples' > > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > > core/command_line.rb:25:in `run' > > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > > core/formatters/base_formatter.rb:37:in `report' > > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > > core/formatters/base_formatter.rb:156:in `sync_output' > > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > > core/formatters/base_formatter.rb:34:in `report' > > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > > core/command_line.rb:22:in `run' > > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > > core/runner.rb:46:in `run_in_process' > > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > > core/runner.rb:37:in `run' > > ? ? # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.19/lib/rspec/ > > core/runner.rb:10 > > ? ? # /usr/bin/rspec:19 > > > daniel at ubuntu/home/daniel/programming/rails_projects/sample_app$ > > > My Gemfile looks like this: > > > daniel at ubuntu/home/daniel/programming/rails_projects/sample_app$ cat > > Gemfile > > source 'http://rubygems.org' > > > gem 'rails', '3.0.0.rc' > > > # Bundle edge Rails instead: > > # gem 'rails', :git => 'git://github.com/rails/rails.git' > > > gem 'sqlite3-ruby', :require => 'sqlite3' > > > group :development, :test do > > ? gem 'rspec-rails', '>= 2.0.0.beta.19' > > end > > > Any ideas what is going on? I am using Ubuntu 10.04 x86_64. > > > Regards, > > > Daniel Lidstr?m > > Stockholm, Sweden > > _______________________________________________ > > rspec-users mailing list > > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users > > I can reproduce this error with webrat version 0.7.2.beta.1 > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users I would suggest switching to capybara. From jko170 at gmail.com Fri Aug 27 23:52:49 2010 From: jko170 at gmail.com (Justin Ko) Date: Fri, 27 Aug 2010 20:52:49 -0700 (PDT) Subject: [rspec-users] respond_to? check in rspec-mocks In-Reply-To: <29e21302-41f8-44b9-b43f-97b3873aadb9@h17g2000pri.googlegroups.com> References: <29e21302-41f8-44b9-b43f-97b3873aadb9@h17g2000pri.googlegroups.com> Message-ID: On Aug 27, 8:18?pm, Myron Marston wrote: > One of the primary dangers of using mocks is that your unit tests may > be testing against an interface that is different from that of your > production objects. ?You may simply have misspelled the method (e.g. > object.should_receive(:methd_name) rather than method_name), or you > may have changed the interface of your production object without > updating your tests. > > Obviously, you should have some integration coverage that will catch > these kinds of errors (and I do), but it's nice when they're caught by > your unit tests since they're so much faster than integration tests. > I've been using a pattern to help with this for a while: > > it "safely mocks a method" do > ? object.should respond_to(:foo) > ? object.should_receive(:foo).and_return(:bar) > ? object.do_something_that_calls_foo > end > > Basically, I add a respond_to? check before mocking or stubbing a > concrete object (obviously, I don't do this for a pure mock object). > If/when I rename the mocked method, I'll get a test failure. ?I think > it'd be nice to add this to rspec-mocks itself. ?A few additional > thoughts about this potential feature: > > * This would only apply when you're mocking/stubbing concrete objects; > on a pure mock or stub it wouldn't do the check. > * Should this print a warning or raise an error so the test fails? > * Should it be configurable? ?I could see some people not wanting this > feature, particularly if you're strictly following the outside-in BDD > process where the specs on the outer layers (say, a controller in a > rails app) mock methods that have not yet been defined on the inner > layers (say, a model in a rails app). > * This feature could potentially take things a step further and when > you specify mock arguments using `with`, it could check the arity of > the method and be sure that the method accepts that number of > arguments. > > What do people think about this idea? > > Myron > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users I'm confused on why you need to use respond_to. The purpose of a stub is to change the behavior of an object. Therefore, if the behavior is *not* being changed, your specs should fail. If the spec does not fail, then the stub was worthless in the first place. I suspect that your specs are not doing their job correctly. Could you provide a real world example and maybe I can provide some pointers? From dlidstrom at gmail.com Sat Aug 28 06:59:49 2010 From: dlidstrom at gmail.com (=?ISO-8859-1?Q?Daniel_Lidstr=F6m?=) Date: Sat, 28 Aug 2010 03:59:49 -0700 (PDT) Subject: [rspec-users] stack level too deep In-Reply-To: <9d740d4a-2ab8-490c-a56c-391ceda29639@z10g2000yqb.googlegroups.com> References: <6ae2a13c-9feb-4a63-8f87-4bb7f4950e23@m1g2000yqo.googlegroups.com> <9d740d4a-2ab8-490c-a56c-391ceda29639@z10g2000yqb.googlegroups.com> Message-ID: <6515bfb1-1ae0-4b05-b809-434111bded16@z28g2000yqh.googlegroups.com> On 28 Aug, 04:13, Justin Ko wrote: > > I would suggest switching to capybara. Hi Justin, I tried changing a part of my Gemfile to this: group :development, :test do gem 'rspec-rails', '>= 2.0.0.beta.19' gem 'capybara' end I am not sure if this is correct or what to do next. I tried "bundle install" and then "rspec spec/requests". Capybara was installed but I still got the stack level too deep error. Could you tell me what to do or point me to an online resource where this is documented? Thanks in advance! Regards, Daniel Lidstr?m Stockholm, Sweden From tjtuom at utu.fi Sat Aug 28 09:23:12 2010 From: tjtuom at utu.fi (Toni Tuominen) Date: Sat, 28 Aug 2010 16:23:12 +0300 Subject: [rspec-users] stack level too deep In-Reply-To: <6515bfb1-1ae0-4b05-b809-434111bded16@z28g2000yqh.googlegroups.com> References: <6ae2a13c-9feb-4a63-8f87-4bb7f4950e23@m1g2000yqo.googlegroups.com> <9d740d4a-2ab8-490c-a56c-391ceda29639@z10g2000yqb.googlegroups.com> <6515bfb1-1ae0-4b05-b809-434111bded16@z28g2000yqh.googlegroups.com> Message-ID: I think you're having this problem: http://github.com/rspec/rspec-rails/issues#issue/140 - Toni On Sat, Aug 28, 2010 at 1:59 PM, Daniel Lidstr?m wrote: > On 28 Aug, 04:13, Justin Ko wrote: >> >> I would suggest switching to capybara. > > Hi Justin, > > I tried changing a part of my Gemfile to this: > > group :development, :test do > ?gem 'rspec-rails', '>= 2.0.0.beta.19' > ?gem 'capybara' > end > > I am not sure if this is correct or what to do next. I tried "bundle > install" and then "rspec spec/requests". Capybara was installed but I > still got the stack level too deep error. Could you tell me what to do > or point me to an online resource where this is documented? > > Thanks in advance! > > Regards, > > Daniel Lidstr?m > Stockholm, Sweden > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From dchelimsky at gmail.com Sat Aug 28 10:36:25 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 28 Aug 2010 09:36:25 -0500 Subject: [rspec-users] respond_to? check in rspec-mocks In-Reply-To: <29e21302-41f8-44b9-b43f-97b3873aadb9@h17g2000pri.googlegroups.com> References: <29e21302-41f8-44b9-b43f-97b3873aadb9@h17g2000pri.googlegroups.com> Message-ID: <5AEC9519-0750-4C8C-8D99-3FC0542B00FB@gmail.com> On Aug 27, 2010, at 7:18 PM, Myron Marston wrote: > One of the primary dangers of using mocks is that your unit tests may > be testing against an interface that is different from that of your > production objects. You may simply have misspelled the method (e.g. > object.should_receive(:methd_name) rather than method_name), or you > may have changed the interface of your production object without > updating your tests. > > Obviously, you should have some integration coverage that will catch > these kinds of errors (and I do), but it's nice when they're caught by > your unit tests since they're so much faster than integration tests. > I've been using a pattern to help with this for a while: > > it "safely mocks a method" do > object.should respond_to(:foo) > object.should_receive(:foo).and_return(:bar) > object.do_something_that_calls_foo > end > > Basically, I add a respond_to? check before mocking or stubbing a > concrete object (obviously, I don't do this for a pure mock object). > If/when I rename the mocked method, I'll get a test failure. I think > it'd be nice to add this to rspec-mocks itself. A few additional > thoughts about this potential feature: > > * This would only apply when you're mocking/stubbing concrete objects; > on a pure mock or stub it wouldn't do the check. > * Should this print a warning or raise an error so the test fails? > * Should it be configurable? I could see some people not wanting this > feature, particularly if you're strictly following the outside-in BDD > process where the specs on the outer layers (say, a controller in a > rails app) mock methods that have not yet been defined on the inner > layers (say, a model in a rails app). > * This feature could potentially take things a step further and when > you specify mock arguments using `with`, it could check the arity of > the method and be sure that the method accepts that number of > arguments. > > What do people think about this idea? > > Myron This idea has come up numerous times on this list over the years, but have yet to see the suggestion or patch that makes it work for me. It's definitely not something I've ever felt RSpec was missing, probably because I tend to write specs at multiple levels and I don't recall ever deploying something to production that failed due to an API getting misaligned. Not saying it's never come up in the development process, but the restrictions imposed by such a feature, in my view, would cost me more than the safety net it provides. My other objection is that we're dealing with a dynamic language here, and there are going to be cases in which methods are defined dynamically. For average users, this is likely not a problem (as long as the check is done at the time the stub is invoked rather than when the stub is defined), but for anyone starting to explore meta-programming this would make things more confusing, IMO. I've also seen plenty of cases where respond_to fails to handle a case that method_missing handles. In these cases, users would get misleading information back, making things more confusing. With all this, there is one idea that I've floated that I'd be open to: an audit flag which could be used to generate a report separate from the spec run. Specs would not fail due to any misalignment, but you'd simply get report saying something like: ############################### Spec: Account#deposit adds deposited amount to its balance # ./spec/bank/account_spec.rb:37 Stub: ledger.record_deposit # ./lib/bank/account.rb:42 - ledger object did not respond to #record_deposit - ledger.methods => [ ... list of public instance methods that are not already part of Object ... ] ############################### This would be disconnected enough from the examples that it would stay out of the way, and it would make misalignments (the common case) easy to see. Thoughts? From dchelimsky at gmail.com Sat Aug 28 10:56:27 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 28 Aug 2010 09:56:27 -0500 Subject: [rspec-users] respond_to? check in rspec-mocks In-Reply-To: References: <29e21302-41f8-44b9-b43f-97b3873aadb9@h17g2000pri.googlegroups.com> Message-ID: <9DC0E7B0-24A5-4E6A-9EE5-AA88E45A4ED1@gmail.com> On Aug 27, 2010, at 10:52 PM, Justin Ko wrote: > > > On Aug 27, 8:18 pm, Myron Marston wrote: >> One of the primary dangers of using mocks is that your unit tests may >> be testing against an interface that is different from that of your >> production objects. You may simply have misspelled the method (e.g. >> object.should_receive(:methd_name) rather than method_name), or you >> may have changed the interface of your production object without >> updating your tests. >> >> Obviously, you should have some integration coverage that will catch >> these kinds of errors (and I do), but it's nice when they're caught by >> your unit tests since they're so much faster than integration tests. >> I've been using a pattern to help with this for a while: >> >> it "safely mocks a method" do >> object.should respond_to(:foo) >> object.should_receive(:foo).and_return(:bar) >> object.do_something_that_calls_foo >> end >> >> Basically, I add a respond_to? check before mocking or stubbing a >> concrete object (obviously, I don't do this for a pure mock object). >> If/when I rename the mocked method, I'll get a test failure. I think >> it'd be nice to add this to rspec-mocks itself. A few additional >> thoughts about this potential feature: >> >> * This would only apply when you're mocking/stubbing concrete objects; >> on a pure mock or stub it wouldn't do the check. >> * Should this print a warning or raise an error so the test fails? >> * Should it be configurable? I could see some people not wanting this >> feature, particularly if you're strictly following the outside-in BDD >> process where the specs on the outer layers (say, a controller in a >> rails app) mock methods that have not yet been defined on the inner >> layers (say, a model in a rails app). >> * This feature could potentially take things a step further and when >> you specify mock arguments using `with`, it could check the arity of >> the method and be sure that the method accepts that number of >> arguments. >> >> What do people think about this idea? >> >> Myron >> _______________________________________________ >> rspec-users mailing list >> rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users > > I'm confused on why you need to use respond_to. The purpose of a stub > is to change the behavior of an object. Therefore, if the behavior is > *not* being changed, your specs should fail. If the spec does not > fail, then the stub was worthless in the first place. Not necessarily. In the case of a stub on a real object, the purpose is to control the environment in which the example runs. Consider a method on an object that returns one value before noon and a different value at noon and after. In an example for another object that depends on the time-dependent object, we might stub that method to respond as though it were before noon in one example, and after noon in another. This means that when you run this spec in the morning, the example that stubs morning-like behaviour is not changing anything or needing to fail. Same for the other example in the afternoon. Cheers, David From dchelimsky at gmail.com Sat Aug 28 11:52:17 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 28 Aug 2010 10:52:17 -0500 Subject: [rspec-users] Autotest will run features, but not specs In-Reply-To: <9E1AF3ED-C464-4037-A3A7-553806CD2CDB@gmail.com> References: <5EAD4227-84BA-4276-AFD1-EDC4F164E672@gmail.com> <4A619CFA-5221-4BB0-8AD5-E56B95E12D86@brennonbortz.com> <9E1AF3ED-C464-4037-A3A7-553806CD2CDB@gmail.com> Message-ID: <6884C697-A668-4A8F-BB34-3239825B7A60@gmail.com> On Aug 27, 2010, at 8:06 AM, David Chelimsky wrote: > On Aug 27, 2010, at 6:47 AM, Brennon Bortz wrote: > >> Not sure what I must have bumped, but autotest won't run any specs--only features. No errors are given on startup. I've taken "export AUTOFEATURE=true" out of my ./bashrc file--now I just get a blank screen when running autotest. Adding "export RSPEC=true" to .bashrc doesn't change anything either. >> >> # ~/.autotest >> require 'autotest/growl' >> >> Autotest.add_hook(:initialize) { |at| >> at.add_exception %r{^\.git} # ignore Version Control System >> at.add_exception %r{^./tmp} # ignore temp files, lest autotest will run again, and again... >> # at.clear_mappings # take out the default (test/test*rb) >> at.add_mapping(%r{^lib/.*\.rb$}) {|f, _| >> Dir['spec/**/*.rb'] >> } >> nil >> } >> >> Autotest.add_hook :initialize do |at| >> at.add_mapping(%r%^spec/(integration)/.*rb$%) {|filename, _| >> filename >> } >> end >> >> # {RAILS_ROOT}/autotest/.discover.rb >> Autotest.add_discovery { "rails" } >> Autotest.add_discovery { "rspec2" } >> >> # {RAILS_ROOT/.rspec >> --format nested >> --color >> >> Output when running autotest: >> >> $ RSPEC=true autotest >> (Not running features. To run features in autotest, set AUTOFEATURE=true.) >> loading autotest/rails >> >> >> -------------------------------------------------------------------------------- >> >> >> And, here are my bundled gems: >> >> Gems included by the bundle: >> * abstract (1.0.0) >> * actionmailer (3.0.0.rc) >> * actionpack (3.0.0.rc) >> * activemodel (3.0.0.rc) >> * activerecord (3.0.0.rc) >> * activeresource (3.0.0.rc) >> * activesupport (3.0.0.rc) >> * arel (0.4.0) >> * builder (2.1.2) >> * bundler (1.0.0.rc.6) >> * capybara (0.3.9) >> * cucumber (0.8.5) >> * cucumber-rails (0.3.2) >> * culerity (0.2.12) >> * diff-lcs (1.1.2) >> * erubis (2.6.6) >> * ffi (0.6.3) >> * gherkin (2.1.5) >> * i18n (0.4.1) >> * json_pure (1.4.6) >> * mail (2.2.5) >> * mime-types (1.16) >> * nokogiri (1.4.3.1) >> * polyglot (0.3.1) >> * rack (1.2.1) >> * rack-mount (0.6.12) >> * rack-test (0.5.4) >> * rails (3.0.0.rc) >> * railties (3.0.0.rc) >> * rake (0.8.7) >> * rspec (2.0.0.beta.20) >> * rspec-core (2.0.0.beta.20) >> * rspec-expectations (2.0.0.beta.20) >> * rspec-mocks (2.0.0.beta.20) >> * rspec-rails (2.0.0.beta.20) >> * rubyzip (0.9.4) >> * selenium-webdriver (0.0.28) >> * sqlite3-ruby (1.3.1) >> * term-ansicolor (1.0.5) >> * thor (0.14.0) >> * treetop (1.4.8) >> * trollop (1.16.2) >> * tzinfo (0.3.23) >> >> This is driving me up the wall...any ideas? > > 1. Get rid of 'Autotest.add_discovery { "rails" }' from ./autotest/discover.rb. > 2. Add autotest-rails to the Gemfile. Apologies - this changed and I forgot. Put "Autotest.add_discovery { "rails" }" back in ./autotest/discover.rb and put autotest (not autotest-rails) in the Gemfile. HTH, David From myron.marston at gmail.com Sat Aug 28 12:32:59 2010 From: myron.marston at gmail.com (Myron Marston) Date: Sat, 28 Aug 2010 09:32:59 -0700 (PDT) Subject: [rspec-users] respond_to? check in rspec-mocks In-Reply-To: <5AEC9519-0750-4C8C-8D99-3FC0542B00FB@gmail.com> References: <29e21302-41f8-44b9-b43f-97b3873aadb9@h17g2000pri.googlegroups.com> <5AEC9519-0750-4C8C-8D99-3FC0542B00FB@gmail.com> Message-ID: > My other objection is that we're dealing with a dynamic > language here, and there are going to be cases in which methods > are defined dynamically. For average users, this is likely not > a problem (as long as the check is done at the time the stub is > invoked rather than when the stub is defined) I was originally thinking the checking would happen when the stub is defined, but I think you're right about it being better to check when the stub is invoked. > I've also seen plenty of cases where respond_to fails to handle > a case that method_missing handles. In these cases, users would > get misleading information back, making things more confusing. That's a valid point, but IMHO an object that overrides method_missing but not respond_to? is pretty poorly behaved object. You're essentially breaking the semantics of how objects are expected to work in ruby. I'd personally want an error or warning when I did this, so that I'm alerted to the problem and can go fix it by properly defining respond_to?. > With all this, there is one idea that I've floated that I'd be > open to: an audit flag which could be used to generate a report > separate from the spec run. Would this report wind up in a separate file that I'd have to open and look at separately? That would reduce the usefulness of this a lot, I think. Instead, could we make it configurable? That way people can set it up to fit their development workflow. I've been thinking that this should be configurable, since people have a variety of development styles. Here's some thoughts about how that configuration could work: * In the RSpec.configure block, you set a default. Something like config.undefined_method_stubs = :error/:warn/nil. * In a spec, you can disable this checking for any object, using something like object.allow_undefined_method_stubs!. This would work well for an object that overrides method_missing, if you really don't want to also override respond_to?. * In a before(:each) block, you can modify the configuration for that example group using something like RSpec::Mocks.undefined_method_stubs = :error/:warn/nil. Note that your separate report idea could easily be accommodated here; it could be an additional allowed value to undefined_method_stubs (maybe :separate_report ?). Myron From jko170 at gmail.com Sat Aug 28 12:33:43 2010 From: jko170 at gmail.com (Justin Ko) Date: Sat, 28 Aug 2010 09:33:43 -0700 (PDT) Subject: [rspec-users] stack level too deep In-Reply-To: <6515bfb1-1ae0-4b05-b809-434111bded16@z28g2000yqh.googlegroups.com> References: <6ae2a13c-9feb-4a63-8f87-4bb7f4950e23@m1g2000yqo.googlegroups.com> <9d740d4a-2ab8-490c-a56c-391ceda29639@z10g2000yqb.googlegroups.com> <6515bfb1-1ae0-4b05-b809-434111bded16@z28g2000yqh.googlegroups.com> Message-ID: <550b5c78-fcfc-42e7-a65e-f22d1f94e6cb@t2g2000yqe.googlegroups.com> On Aug 28, 6:59?am, Daniel Lidstr?m wrote: > On 28 Aug, 04:13, Justin Ko wrote: > > > > > I would suggest switching to capybara. > > Hi Justin, > > I tried changing a part of my Gemfile to this: > > group :development, :test do > ? gem 'rspec-rails', '>= 2.0.0.beta.19' > ? gem 'capybara' > end > > I am not sure if this is correct or what to do next. I tried "bundle > install" and then "rspec spec/requests". Capybara was installed but I > still got the stack level too deep error. Could you tell me what to do > or point me to an online resource where this is documented? > > Thanks in advance! > > Regards, > > Daniel Lidstr?m > Stockholm, Sweden > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users Did you remove webrat from the Gemfile? From jko170 at gmail.com Sat Aug 28 12:59:18 2010 From: jko170 at gmail.com (Justin Ko) Date: Sat, 28 Aug 2010 09:59:18 -0700 (PDT) Subject: [rspec-users] respond_to? check in rspec-mocks In-Reply-To: <9DC0E7B0-24A5-4E6A-9EE5-AA88E45A4ED1@gmail.com> References: <29e21302-41f8-44b9-b43f-97b3873aadb9@h17g2000pri.googlegroups.com> <9DC0E7B0-24A5-4E6A-9EE5-AA88E45A4ED1@gmail.com> Message-ID: <08cb9f21-dd4a-41a6-a533-2d8e5dbb28dd@j18g2000yqd.googlegroups.com> > Not necessarily. In the case of a stub on a real object, the purpose is to control the environment in which the example runs. Consider a method on an object that returns one value before noon and a different value at noon and after. In an example for another object that depends on the time-dependent object, we might stub that method to respond as though it were before noon in one example, and after noon in another. This means that when you run this spec in the morning, the example that stubs morning-like behaviour is not changing anything or needing to fail. Same for the other example in the afternoon. > > Cheers, > David This is true, but the "morning" spec would fail in the afternoon (or/ and the afternoon spec would fail in the morning). If the stub is not being touched, it should fail *at some point in time*. If the stub is not being touched, yet your specs are passing, then technically there is nothing wrong with your app. From dchelimsky at gmail.com Sat Aug 28 13:32:26 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 28 Aug 2010 12:32:26 -0500 Subject: [rspec-users] stack level too deep In-Reply-To: <550b5c78-fcfc-42e7-a65e-f22d1f94e6cb@t2g2000yqe.googlegroups.com> References: <6ae2a13c-9feb-4a63-8f87-4bb7f4950e23@m1g2000yqo.googlegroups.com> <9d740d4a-2ab8-490c-a56c-391ceda29639@z10g2000yqb.googlegroups.com> <6515bfb1-1ae0-4b05-b809-434111bded16@z28g2000yqh.googlegroups.com> <550b5c78-fcfc-42e7-a65e-f22d1f94e6cb@t2g2000yqe.googlegroups.com> Message-ID: On Aug 28, 2010, at 11:33 AM, Justin Ko wrote: > > > On Aug 28, 6:59 am, Daniel Lidstr?m wrote: >> On 28 Aug, 04:13, Justin Ko wrote: >> >> >> >>> I would suggest switching to capybara. >> >> Hi Justin, >> >> I tried changing a part of my Gemfile to this: >> >> group :development, :test do >> gem 'rspec-rails', '>= 2.0.0.beta.19' >> gem 'capybara' >> end >> >> I am not sure if this is correct or what to do next. I tried "bundle >> install" and then "rspec spec/requests". Capybara was installed but I >> still got the stack level too deep error. Could you tell me what to do >> or point me to an online resource where this is documented? >> >> Thanks in advance! >> >> Regards, >> >> Daniel Lidstr?m >> Stockholm, Sweden >> _______________________________________________ >> rspec-users mailing list >> rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users > > Did you remove webrat from the Gemfile? That won't help with beta.19, which has a hard dependency on webrat. beta.20 does not, so you can choose between webrat and capybara. From dchelimsky at gmail.com Sat Aug 28 14:01:59 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 28 Aug 2010 13:01:59 -0500 Subject: [rspec-users] respond_to? check in rspec-mocks In-Reply-To: References: <29e21302-41f8-44b9-b43f-97b3873aadb9@h17g2000pri.googlegroups.com> <5AEC9519-0750-4C8C-8D99-3FC0542B00FB@gmail.com> Message-ID: On Aug 28, 2010, at 11:32 AM, Myron Marston wrote: >> My other objection is that we're dealing with a dynamic >> language here, and there are going to be cases in which methods >> are defined dynamically. For average users, this is likely not >> a problem (as long as the check is done at the time the stub is >> invoked rather than when the stub is defined) > > I was originally thinking the checking would happen when the stub is > defined, but I think you're right about it being better to check when > the stub is invoked. > >> I've also seen plenty of cases where respond_to fails to handle >> a case that method_missing handles. In these cases, users would >> get misleading information back, making things more confusing. > > That's a valid point, but IMHO an object that overrides method_missing > but not respond_to? is pretty poorly behaved object. You're > essentially breaking the semantics of how objects are expected to work > in ruby. Agreed, but in pretty much every case that I've seen this it's been in a 3rd party library that I am not in control of. > I'd personally want an error or warning when I did this, so > that I'm alerted to the problem and can go fix it by properly defining > respond_to?. Interesting side effect of this. I can see how this can help nudge a developer in the right direction. >> With all this, there is one idea that I've floated that I'd be >> open to: an audit flag which could be used to generate a report >> separate from the spec run. > > Would this report wind up in a separate file that I'd have to open and > look at separately? I think "separate from the spec run" mislead you as to my intention here. What I mean is that I don't want this to raise errors, but rather it would be part of the output, just like pending and failed examples. > That would reduce the usefulness of this a lot, I > think. > > Instead, could we make it configurable? That way people can set it up > to fit their development workflow. I've been thinking that this > should be configurable, since people have a variety of development > styles. Here's some thoughts about how that configuration could work: > > * In the RSpec.configure block, you set a default. Something like > config.undefined_method_stubs = :error/:warn/nil. > * In a spec, you can disable this checking for any object, using > something like object.allow_undefined_method_stubs!. This would work > well for an object that overrides method_missing, if you really don't > want to also override respond_to?. > * In a before(:each) block, you can modify the configuration for that > example group using something like RSpec::Mocks.undefined_method_stubs > = :error/:warn/nil. I was resistant to the idea when it was simpler, but this additional complexity makes me even moreso :) Without getting into a debate about its relative merits, here's what I'd really like to see: an API in the rspec-mocks framework that would allow you to extend it to do all this in a separate gem. Then you could build this, release it, refine it, etc. What do you think would be necessary in rspec-mocks to support that? > Note that your separate report idea could easily be accommodated here; > it could be an additional allowed value to undefined_method_stubs > (maybe :separate_report ?). No need for a separate report - again - poor choice of words on my part. > Myron From dlidstrom at gmail.com Sat Aug 28 14:44:54 2010 From: dlidstrom at gmail.com (=?ISO-8859-1?Q?Daniel_Lidstr=F6m?=) Date: Sat, 28 Aug 2010 11:44:54 -0700 (PDT) Subject: [rspec-users] stack level too deep In-Reply-To: References: <6ae2a13c-9feb-4a63-8f87-4bb7f4950e23@m1g2000yqo.googlegroups.com> <9d740d4a-2ab8-490c-a56c-391ceda29639@z10g2000yqb.googlegroups.com> <6515bfb1-1ae0-4b05-b809-434111bded16@z28g2000yqh.googlegroups.com> <550b5c78-fcfc-42e7-a65e-f22d1f94e6cb@t2g2000yqe.googlegroups.com> Message-ID: <3f2ff1d8-5525-490b-a6d3-71309c3aed58@f6g2000yqa.googlegroups.com> On 28 Aug, 19:32, David Chelimsky wrote: > On Aug 28, 2010, at 11:33 AM, Justin Ko wrote: > > > Did you remove webrat from the Gemfile? > > That won't help with beta.19, which has a hard dependency on webrat. beta.20 does not, so you can choose between webrat and capybara. Thanks for the responses so far. Here's what I have done: - Switched to beta 20: daniel at ubuntu/home/daniel/programming/rails_projects/sample_app$ cat Gemfile source 'http://rubygems.org' gem 'rails', '3.0.0.rc' # Bundle edge Rails instead: # gem 'rails', :git => 'git://github.com/rails/rails.git' gem 'sqlite3-ruby', :require => 'sqlite3' group :development, :test do gem 'rspec-rails', '>= 2.0.0.beta.20' gem 'capybara' end - Updated rspec: daniel at ubuntu/home/daniel/programming/rails_projects/sample_app$ rails generate rspec:install identical .rspec exist spec conflict spec/spec_helper.rb Overwrite /home/daniel/programming/rails_projects/sample_app/spec/ spec_helper.rb? (enter "h" for help) [Ynaqdh] Y force spec/spec_helper.rb exist autotest identical autotest/discover.rb - Then run the tests again: daniel at ubuntu/home/daniel/programming/rails_projects/sample_app$ rspec -b spec FFFF.F.F.F Failures: 1) LayoutLinks should have a Home page at '/' Failure/Error: response.should have_selector('title', :content => "Home") undefined method `has_selector?' for # # /usr/lib/ruby/gems/1.8/gems/rspec-expectations-2.0.0.beta.20/ lib/rspec/matchers/has.rb:11:in `__send__' # /usr/lib/ruby/gems/1.8/gems/rspec-expectations-2.0.0.beta.20/ lib/rspec/matchers/has.rb:11:in `matches?' # /usr/lib/ruby/gems/1.8/gems/rspec-expectations-2.0.0.beta.20/ lib/rspec/expectations/handler.rb:11:in `handle_matcher' # /usr/lib/ruby/gems/1.8/gems/rspec-expectations-2.0.0.beta.20/ lib/rspec/expectations/extensions/kernel.rb:27:in `should' # ./spec/requests/layout_links_spec.rb:7 # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ core/example.rb:52:in `instance_eval' # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ core/example.rb:52 # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ core/example.rb:86:in `call' # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ core/example.rb:86:in `with_around_hooks' # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ core/example.rb:48 # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ core/example.rb:80:in `call' # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ core/example.rb:80:in `with_pending_capture' # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ core/example.rb:79:in `catch' # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ core/example.rb:79:in `with_pending_capture' # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ core/example.rb:47:in `run' # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ core/example_group.rb:222:in `run_examples' # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ core/example_group.rb:219:in `map' # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ core/example_group.rb:219:in `run_examples' # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ core/example_group.rb:210:in `run' # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ core/command_line.rb:43:in `run_examples' # /home/daniel/.gem/ruby/1.8/gems/activesupport-3.0.0.rc/lib/ active_support/dependencies.rb:219:in `inject' # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ core/command_line.rb:43:in `each' # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ core/command_line.rb:43:in `inject' # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ core/command_line.rb:43:in `run_examples' # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ core/command_line.rb:26:in `run' # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ core/reporter.rb:11:in `report' # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ core/command_line.rb:23:in `run' # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ core/runner.rb:46:in `run_in_process' # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ core/runner.rb:37:in `run' # /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ core/runner.rb:10 # /usr/bin/rspec:19 . . . I don't know what to do from here? From jko170 at gmail.com Sat Aug 28 14:59:43 2010 From: jko170 at gmail.com (Justin Ko) Date: Sat, 28 Aug 2010 11:59:43 -0700 (PDT) Subject: [rspec-users] stack level too deep In-Reply-To: <3f2ff1d8-5525-490b-a6d3-71309c3aed58@f6g2000yqa.googlegroups.com> References: <6ae2a13c-9feb-4a63-8f87-4bb7f4950e23@m1g2000yqo.googlegroups.com> <9d740d4a-2ab8-490c-a56c-391ceda29639@z10g2000yqb.googlegroups.com> <6515bfb1-1ae0-4b05-b809-434111bded16@z28g2000yqh.googlegroups.com> <550b5c78-fcfc-42e7-a65e-f22d1f94e6cb@t2g2000yqe.googlegroups.com> <3f2ff1d8-5525-490b-a6d3-71309c3aed58@f6g2000yqa.googlegroups.com> Message-ID: On Aug 28, 2:44?pm, Daniel Lidstr?m wrote: > On 28 Aug, 19:32, David Chelimsky wrote: > > > On Aug 28, 2010, at 11:33 AM, Justin Ko wrote: > > > > Did you remove webrat from the Gemfile? > > > That won't help with beta.19, which has a hard dependency on webrat. beta.20 does not, so you can choose between webrat and capybara. > > Thanks for the responses so far. Here's what I have done: > > - Switched to beta 20: > > daniel at ubuntu/home/daniel/programming/rails_projects/sample_app$ cat > Gemfile > source 'http://rubygems.org' > > gem 'rails', '3.0.0.rc' > > # Bundle edge Rails instead: > # gem 'rails', :git => 'git://github.com/rails/rails.git' > > gem 'sqlite3-ruby', :require => 'sqlite3' > > group :development, :test do > ? gem 'rspec-rails', '>= 2.0.0.beta.20' > ? gem 'capybara' > end > > - Updated rspec: > > daniel at ubuntu/home/daniel/programming/rails_projects/sample_app$ rails > generate rspec:install > ? ?identical ?.rspec > ? ? ? ?exist ?spec > ? ? conflict ?spec/spec_helper.rb > Overwrite /home/daniel/programming/rails_projects/sample_app/spec/ > spec_helper.rb? (enter "h" for help) [Ynaqdh] Y > ? ? ? ?force ?spec/spec_helper.rb > ? ? ? ?exist ?autotest > ? ?identical ?autotest/discover.rb > > - Then run the tests again: > > daniel at ubuntu/home/daniel/programming/rails_projects/sample_app$ rspec > -b spec > FFFF.F.F.F > > Failures: > ? 1) LayoutLinks should have a Home page at '/' > ? ? ?Failure/Error: response.should have_selector('title', :content => > "Home") > ? ? ?undefined method `has_selector?' for > # > ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-expectations-2.0.0.beta.20/ > lib/rspec/matchers/has.rb:11:in `__send__' > ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-expectations-2.0.0.beta.20/ > lib/rspec/matchers/has.rb:11:in `matches?' > ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-expectations-2.0.0.beta.20/ > lib/rspec/expectations/handler.rb:11:in `handle_matcher' > ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-expectations-2.0.0.beta.20/ > lib/rspec/expectations/extensions/kernel.rb:27:in `should' > ? ? ?# ./spec/requests/layout_links_spec.rb:7 > ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ > core/example.rb:52:in `instance_eval' > ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ > core/example.rb:52 > ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ > core/example.rb:86:in `call' > ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ > core/example.rb:86:in `with_around_hooks' > ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ > core/example.rb:48 > ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ > core/example.rb:80:in `call' > ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ > core/example.rb:80:in `with_pending_capture' > ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ > core/example.rb:79:in `catch' > ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ > core/example.rb:79:in `with_pending_capture' > ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ > core/example.rb:47:in `run' > ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ > core/example_group.rb:222:in `run_examples' > ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ > core/example_group.rb:219:in `map' > ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ > core/example_group.rb:219:in `run_examples' > ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ > core/example_group.rb:210:in `run' > ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ > core/command_line.rb:43:in `run_examples' > ? ? ?# /home/daniel/.gem/ruby/1.8/gems/activesupport-3.0.0.rc/lib/ > active_support/dependencies.rb:219:in `inject' > ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ > core/command_line.rb:43:in `each' > ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ > core/command_line.rb:43:in `inject' > ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ > core/command_line.rb:43:in `run_examples' > ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ > core/command_line.rb:26:in `run' > ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ > core/reporter.rb:11:in `report' > ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ > core/command_line.rb:23:in `run' > ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ > core/runner.rb:46:in `run_in_process' > ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ > core/runner.rb:37:in `run' > ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ > core/runner.rb:10 > ? ? ?# /usr/bin/rspec:19 > . > . > . > > I don't know what to do from here? > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users Did you run bundle install? From tjtuom at utu.fi Sat Aug 28 15:21:42 2010 From: tjtuom at utu.fi (Toni Tuominen) Date: Sat, 28 Aug 2010 22:21:42 +0300 Subject: [rspec-users] stack level too deep In-Reply-To: References: <6ae2a13c-9feb-4a63-8f87-4bb7f4950e23@m1g2000yqo.googlegroups.com> <9d740d4a-2ab8-490c-a56c-391ceda29639@z10g2000yqb.googlegroups.com> <6515bfb1-1ae0-4b05-b809-434111bded16@z28g2000yqh.googlegroups.com> <550b5c78-fcfc-42e7-a65e-f22d1f94e6cb@t2g2000yqe.googlegroups.com> <3f2ff1d8-5525-490b-a6d3-71309c3aed58@f6g2000yqa.googlegroups.com> Message-ID: Have selector is a webrat matcher. If you're not using webrat you can't use it. Capybara's matcher is have_css. I suggest you take a look at capybara docs. - Toni On Sat, Aug 28, 2010 at 9:59 PM, Justin Ko wrote: > > > On Aug 28, 2:44?pm, Daniel Lidstr?m wrote: >> On 28 Aug, 19:32, David Chelimsky wrote: >> >> > On Aug 28, 2010, at 11:33 AM, Justin Ko wrote: >> >> > > Did you remove webrat from the Gemfile? >> >> > That won't help with beta.19, which has a hard dependency on webrat. beta.20 does not, so you can choose between webrat and capybara. >> >> Thanks for the responses so far. Here's what I have done: >> >> - Switched to beta 20: >> >> daniel at ubuntu/home/daniel/programming/rails_projects/sample_app$ cat >> Gemfile >> source 'http://rubygems.org' >> >> gem 'rails', '3.0.0.rc' >> >> # Bundle edge Rails instead: >> # gem 'rails', :git => 'git://github.com/rails/rails.git' >> >> gem 'sqlite3-ruby', :require => 'sqlite3' >> >> group :development, :test do >> ? gem 'rspec-rails', '>= 2.0.0.beta.20' >> ? gem 'capybara' >> end >> >> - Updated rspec: >> >> daniel at ubuntu/home/daniel/programming/rails_projects/sample_app$ rails >> generate rspec:install >> ? ?identical ?.rspec >> ? ? ? ?exist ?spec >> ? ? conflict ?spec/spec_helper.rb >> Overwrite /home/daniel/programming/rails_projects/sample_app/spec/ >> spec_helper.rb? (enter "h" for help) [Ynaqdh] Y >> ? ? ? ?force ?spec/spec_helper.rb >> ? ? ? ?exist ?autotest >> ? ?identical ?autotest/discover.rb >> >> - Then run the tests again: >> >> daniel at ubuntu/home/daniel/programming/rails_projects/sample_app$ rspec >> -b spec >> FFFF.F.F.F >> >> Failures: >> ? 1) LayoutLinks should have a Home page at '/' >> ? ? ?Failure/Error: response.should have_selector('title', :content => >> "Home") >> ? ? ?undefined method `has_selector?' for >> # >> ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-expectations-2.0.0.beta.20/ >> lib/rspec/matchers/has.rb:11:in `__send__' >> ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-expectations-2.0.0.beta.20/ >> lib/rspec/matchers/has.rb:11:in `matches?' >> ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-expectations-2.0.0.beta.20/ >> lib/rspec/expectations/handler.rb:11:in `handle_matcher' >> ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-expectations-2.0.0.beta.20/ >> lib/rspec/expectations/extensions/kernel.rb:27:in `should' >> ? ? ?# ./spec/requests/layout_links_spec.rb:7 >> ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ >> core/example.rb:52:in `instance_eval' >> ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ >> core/example.rb:52 >> ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ >> core/example.rb:86:in `call' >> ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ >> core/example.rb:86:in `with_around_hooks' >> ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ >> core/example.rb:48 >> ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ >> core/example.rb:80:in `call' >> ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ >> core/example.rb:80:in `with_pending_capture' >> ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ >> core/example.rb:79:in `catch' >> ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ >> core/example.rb:79:in `with_pending_capture' >> ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ >> core/example.rb:47:in `run' >> ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ >> core/example_group.rb:222:in `run_examples' >> ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ >> core/example_group.rb:219:in `map' >> ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ >> core/example_group.rb:219:in `run_examples' >> ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ >> core/example_group.rb:210:in `run' >> ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ >> core/command_line.rb:43:in `run_examples' >> ? ? ?# /home/daniel/.gem/ruby/1.8/gems/activesupport-3.0.0.rc/lib/ >> active_support/dependencies.rb:219:in `inject' >> ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ >> core/command_line.rb:43:in `each' >> ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ >> core/command_line.rb:43:in `inject' >> ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ >> core/command_line.rb:43:in `run_examples' >> ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ >> core/command_line.rb:26:in `run' >> ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ >> core/reporter.rb:11:in `report' >> ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ >> core/command_line.rb:23:in `run' >> ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ >> core/runner.rb:46:in `run_in_process' >> ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ >> core/runner.rb:37:in `run' >> ? ? ?# /usr/lib/ruby/gems/1.8/gems/rspec-core-2.0.0.beta.20/lib/rspec/ >> core/runner.rb:10 >> ? ? ?# /usr/bin/rspec:19 >> . >> . >> . >> >> I don't know what to do from here? >> _______________________________________________ >> rspec-users mailing list >> rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users > > Did you run bundle install? > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From dlidstrom at gmail.com Sat Aug 28 16:50:28 2010 From: dlidstrom at gmail.com (=?ISO-8859-1?Q?Daniel_Lidstr=F6m?=) Date: Sat, 28 Aug 2010 13:50:28 -0700 (PDT) Subject: [rspec-users] stack level too deep In-Reply-To: References: <6ae2a13c-9feb-4a63-8f87-4bb7f4950e23@m1g2000yqo.googlegroups.com> <9d740d4a-2ab8-490c-a56c-391ceda29639@z10g2000yqb.googlegroups.com> <6515bfb1-1ae0-4b05-b809-434111bded16@z28g2000yqh.googlegroups.com> <550b5c78-fcfc-42e7-a65e-f22d1f94e6cb@t2g2000yqe.googlegroups.com> <3f2ff1d8-5525-490b-a6d3-71309c3aed58@f6g2000yqa.googlegroups.com> Message-ID: <88bb6cfb-3e1d-4c39-9a70-797e632cf9f2@i13g2000yqe.googlegroups.com> On 28 Aug, 21:21, Toni Tuominen wrote: > Have selector is a webrat matcher. If you're not using webrat you > can't use it. Capybara's matcher is have_css. I suggest you take a > look at capybara docs. > > - Toni Aha, that makes perfect sense Toni. Thanks! Daniel From michael at schuerig.de Sat Aug 28 19:12:53 2010 From: michael at schuerig.de (Michael Schuerig) Date: Sun, 29 Aug 2010 01:12:53 +0200 Subject: [rspec-users] RSpec 2/Rails 3 - content_for in view specs In-Reply-To: References: Message-ID: <201008290112.54287.michael@schuerig.de> On Thursday 19 August 2010, Dylan Markow wrote: > Is there a way to get to the content captured in a "content_for" > block through my view specs, or at the very least get my "render" > call to use the full layout? Try defining a method like this in your spec def content_for(name) view.instance_variable_get(:@_content_for)[name] end and then content_for(:sidebar).should ... Michael -- Michael Schuerig mailto:michael at schuerig.de http://www.schuerig.de/michael/ From myron.marston at gmail.com Sun Aug 29 02:30:55 2010 From: myron.marston at gmail.com (Myron Marston) Date: Sat, 28 Aug 2010 23:30:55 -0700 (PDT) Subject: [rspec-users] respond_to? check in rspec-mocks In-Reply-To: References: <29e21302-41f8-44b9-b43f-97b3873aadb9@h17g2000pri.googlegroups.com> <5AEC9519-0750-4C8C-8D99-3FC0542B00FB@gmail.com> Message-ID: > I think "separate from the spec run" mislead you as to my intention here. > What I mean is that I don't want this to raise errors, but rather it > would be part of the output, just like pending and failed examples. I'm OK with this idea. I just didn't want to have a separate file to read :). > I was resistant to the idea when it was simpler, but this additional > complexity makes me even moreso :) Fair enough. > Without getting into a debate about its relative merits, here's what > I'd really like to see: an API in the rspec-mocks framework that would > allow you to extend it to do all this in a separate gem. Then you > could build this, release it, refine it, etc. > > What do you think would be necessary in rspec-mocks to support that? I appreciate your willingness to make changes to RSpec to support 3rd party libraries...but I honestly think that the necessary changes to rspec-mocks for the API plus the separate gem would be far more work than just implementing a simple version of this (as you've suggested) in rspec mocks itself. Plus I doubt that a separate gem that did this one simple thing would get much use by other developers. Now that I understand that you just meant to have this print out a report as part of the main spec output, I'm completely satisfied with your suggestion. I'll start working on something in a branch and I'll see what I can come up with. Myron From dchelimsky at gmail.com Sun Aug 29 18:51:19 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 29 Aug 2010 17:51:19 -0500 Subject: [rspec-users] respond_to? check in rspec-mocks In-Reply-To: References: <29e21302-41f8-44b9-b43f-97b3873aadb9@h17g2000pri.googlegroups.com> <5AEC9519-0750-4C8C-8D99-3FC0542B00FB@gmail.com> Message-ID: On Aug 29, 2010, at 1:30 AM, Myron Marston wrote: >> I think "separate from the spec run" mislead you as to my intention here. >> What I mean is that I don't want this to raise errors, but rather it >> would be part of the output, just like pending and failed examples. > > I'm OK with this idea. I just didn't want to have a separate file to > read :). > >> I was resistant to the idea when it was simpler, but this additional >> complexity makes me even moreso :) > > Fair enough. > >> Without getting into a debate about its relative merits, here's what >> I'd really like to see: an API in the rspec-mocks framework that would >> allow you to extend it to do all this in a separate gem. Then you >> could build this, release it, refine it, etc. >> >> What do you think would be necessary in rspec-mocks to support that? > > I appreciate your willingness to make changes to RSpec to support 3rd > party libraries...but I honestly think that the necessary changes to > rspec-mocks for the API plus the separate gem would be far more work > than just implementing a simple version of this (as you've suggested) > in rspec mocks itself. Plus I doubt that a separate gem that did this > one simple thing would get much use by other developers. > > Now that I understand that you just meant to have this print out a > report as part of the main spec output, I'm completely satisfied with > your suggestion. I'll start working on something in a branch and I'll > see what I can come up with. Cool. Thanks. Cheers, David From akleak at gmail.com Sun Aug 29 23:52:53 2010 From: akleak at gmail.com (Arco) Date: Sun, 29 Aug 2010 20:52:53 -0700 (PDT) Subject: [rspec-users] Rspec2 ETA ?? Message-ID: <9097b803-5f7c-4688-b159-4403b142e759@s24g2000pri.googlegroups.com> Is there an ETA for a production version of Rspec2 ?? From akleak at gmail.com Sun Aug 29 23:52:53 2010 From: akleak at gmail.com (Arco) Date: Sun, 29 Aug 2010 20:52:53 -0700 (PDT) Subject: [rspec-users] Rspec2 ETA ?? Message-ID: <9097b803-5f7c-4688-b159-4403b142e759@s24g2000pri.googlegroups.com> Is there an ETA for a production version of Rspec2 ?? From akleak at gmail.com Sun Aug 29 23:52:53 2010 From: akleak at gmail.com (Arco) Date: Sun, 29 Aug 2010 20:52:53 -0700 (PDT) Subject: [rspec-users] Rspec2 ETA ?? Message-ID: <9097b803-5f7c-4688-b159-4403b142e759@s24g2000pri.googlegroups.com> Is there an ETA for a production version of Rspec2 ?? From nathanvda at gmail.com Mon Aug 30 03:59:28 2010 From: nathanvda at gmail.com (nathanvda) Date: Mon, 30 Aug 2010 00:59:28 -0700 (PDT) Subject: [rspec-users] rspec2: autotest keeps rerunning failing tests Message-ID: <6695fcfe-dbd1-47d0-9938-f227f0b16125@q22g2000yqm.googlegroups.com> Since my update to beta.20 i have this weird thing. Normally i develop with autotest on, and when i get an error: i can check the errors, and they are rerun when i save the files. If all my tests pass this is still the current behaviour, but if i have failing tests, autotest will keep running those tests. I am afraid i find that kind of annoying :) I am not sure what could cause this. In my autotest/discover.rb i have the following lines: Autotest.add_discovery { "rails" } Autotest.add_discovery { "rspec2" } Is there a way to get the old behaviour back? (tests are only rerun when files have changed) From win at wincent.com Mon Aug 30 04:22:53 2010 From: win at wincent.com (Wincent Colaiuta) Date: Mon, 30 Aug 2010 10:22:53 +0200 Subject: [rspec-users] Rspec2 ETA ?? In-Reply-To: <9097b803-5f7c-4688-b159-4403b142e759@s24g2000pri.googlegroups.com> References: <9097b803-5f7c-4688-b159-4403b142e759@s24g2000pri.googlegroups.com> Message-ID: <0C441FDE-6AE7-48E0-B387-92495165101F@wincent.com> El 30/08/2010, a las 05:52, Arco escribi?: > Is there an ETA for a production version of Rspec2 ?? I'll let David answer that one, but as a humble user, having used the betas of RSpec 2 for a few months now I'd say it's certainly production-ready. I'd deploy the latest beta to production servers without hesitation. Cheers, Wincent From nathanvda at gmail.com Mon Aug 30 08:00:29 2010 From: nathanvda at gmail.com (nathanvda) Date: Mon, 30 Aug 2010 05:00:29 -0700 (PDT) Subject: [rspec-users] rspec2: autotest keeps rerunning failing tests In-Reply-To: <6695fcfe-dbd1-47d0-9938-f227f0b16125@q22g2000yqm.googlegroups.com> References: <6695fcfe-dbd1-47d0-9938-f227f0b16125@q22g2000yqm.googlegroups.com> Message-ID: <71e7f167-69c1-47c8-b396-7b86d27ffea4@t20g2000yqa.googlegroups.com> I can't explain why it suddenly did not work anymore, but i read http://gist.github.com/365816 and the only thing i needed to do to make it work was adding the following dependencies to my gemfile: gem "autotest" gem "autotest-rails" The gem autotest-rails was already installed on my system. So can't explain why, but now it works. There, i fixed it :) On Aug 30, 9:59?am, nathanvda wrote: > Since my update to beta.20 i have this weird thing. > Normally i develop with autotest on, and when i get an error: i can > check the errors, and they are rerun when i save the files. > > If all my tests pass this is still the current behaviour, but if i > have failing tests, autotest will keep running those tests. > I am afraid i find that kind of annoying :) > > I am not sure what could cause this. > > In my autotest/discover.rb i have the following lines: > > Autotest.add_discovery { "rails" } > Autotest.add_discovery { "rspec2" } > > Is there a way to get the old behaviour back? (tests are only rerun > when files have changed) > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users From matt at mattwynne.net Mon Aug 30 09:21:26 2010 From: matt at mattwynne.net (Matt Wynne) Date: Mon, 30 Aug 2010 14:21:26 +0100 Subject: [rspec-users] Default format for all requests in a spec In-Reply-To: References: Message-ID: Or you could override the #get/post/put/delete methods in your ExampleGroup describe MyController do def get(path, params) super(path, params.merge({:format => 'js'}) end it '...' do get :show, :id => 1 end end On 27 Aug 2010, at 08:00, Justin Ko wrote: > Well, you could setup a default parameter hash: > > describe MyController do > let(:params) { {:format => 'js'} } > > describe '#show' do > it '...' do > get :show, params.merge(:id => 1) > end > end > end > > You could also take it another level: > > describe MyController do > let(:params) { {:format => 'js'} } > > describe '#show' do > before { params.merge(:id => 1) } > > it '...' do > get :show, params.merge(:another_param => 'yep') > end > end > end > > On Aug 26, 9:12 am, Maur?cio Linhares > wrote: >> Hi guys, >> >> Is there a way to define a default parameter for all requests made in a spec? >> >> I have a spec where I want all requests to be made with the "js" >> format but I find it rather annoying to type a ":format => 'js'" on >> every get/post/put/delete. Is there any other way to do this? >> >> - >> Maur?cio Linhareshttp://codeshooter.wordpress.com/|http://twitter.com/mauriciojr >> _______________________________________________ >> rspec-users mailing list >> rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users cheers, Matt http://blog.mattwynne.net +44(0)7974 430184 From dchelimsky at gmail.com Mon Aug 30 09:47:40 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 30 Aug 2010 08:47:40 -0500 Subject: [rspec-users] Rspec2 ETA ?? In-Reply-To: <0C441FDE-6AE7-48E0-B387-92495165101F@wincent.com> References: <9097b803-5f7c-4688-b159-4403b142e759@s24g2000pri.googlegroups.com> <0C441FDE-6AE7-48E0-B387-92495165101F@wincent.com> Message-ID: <4AEC1E84-B707-4E01-9B29-F30E1B87B490@gmail.com> On Aug 30, 2010, at 3:22 AM, Wincent Colaiuta wrote: > El 30/08/2010, a las 05:52, Arco escribi?: > >> Is there an ETA for a production version of Rspec2 ?? > > I'll let David answer that one, but as a humble user, having used the betas of RSpec 2 for a few months now I'd say it's certainly production-ready. I'd deploy the latest beta to production servers without hesitation. That's great to hear, Wincent. In answer to the ETA question: there are only a couple of issues that remain in terms of the code, but the biggest hurdle right now is documentation. I don't want to release 2.0.0 without clear, concise, and thorough documentation. So if people want to help us get there, the best thing would be to submit patches with either additional rdoc for public methods or new cucumber scenarios for features that aren't yet documented with them. I'll follow up tonight or later this week with a more precise description of what this means. Cheers, David From jko170 at gmail.com Mon Aug 30 10:56:16 2010 From: jko170 at gmail.com (Justin Ko) Date: Mon, 30 Aug 2010 07:56:16 -0700 (PDT) Subject: [rspec-users] rspec2: autotest keeps rerunning failing tests In-Reply-To: <71e7f167-69c1-47c8-b396-7b86d27ffea4@t20g2000yqa.googlegroups.com> References: <6695fcfe-dbd1-47d0-9938-f227f0b16125@q22g2000yqm.googlegroups.com> <71e7f167-69c1-47c8-b396-7b86d27ffea4@t20g2000yqa.googlegroups.com> Message-ID: <85022101-9fbc-40bc-ab34-6ade946aad7f@q22g2000yqm.googlegroups.com> hmmmm.... adding autotest-rails did not fix it for me. On Aug 30, 8:00?am, nathanvda wrote: > I can't explain why it suddenly did not work anymore, but i readhttp://gist.github.com/365816 > and the only thing i needed to do to make it work was adding the > following dependencies to my gemfile: > > gem "autotest" > gem "autotest-rails" > > The gem autotest-rails was already installed on my system. So can't > explain why, but now it works. > There, i fixed it :) > > On Aug 30, 9:59?am, nathanvda wrote: > > > > > Since my update to beta.20 i have this weird thing. > > Normally i develop with autotest on, and when i get an error: i can > > check the errors, and they are rerun when i save the files. > > > If all my tests pass this is still the current behaviour, but if i > > have failing tests, autotest will keep running those tests. > > I am afraid i find that kind of annoying :) > > > I am not sure what could cause this. > > > In my autotest/discover.rb i have the following lines: > > > Autotest.add_discovery { "rails" } > > Autotest.add_discovery { "rspec2" } > > > Is there a way to get the old behaviour back? (tests are only rerun > > when files have changed) > > _______________________________________________ > > rspec-users mailing list > > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users > > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users From dchelimsky at gmail.com Mon Aug 30 11:08:40 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 30 Aug 2010 10:08:40 -0500 Subject: [rspec-users] rspec2: autotest keeps rerunning failing tests In-Reply-To: <85022101-9fbc-40bc-ab34-6ade946aad7f@q22g2000yqm.googlegroups.com> References: <6695fcfe-dbd1-47d0-9938-f227f0b16125@q22g2000yqm.googlegroups.com> <71e7f167-69c1-47c8-b396-7b86d27ffea4@t20g2000yqa.googlegroups.com> <85022101-9fbc-40bc-ab34-6ade946aad7f@q22g2000yqm.googlegroups.com> Message-ID: <2FC8921D-CDCB-4596-903A-FE98A76E4EB7@gmail.com> On Aug 30, 2010, at 9:56 AM, Justin Ko wrote: > On Aug 30, 8:00 am, nathanvda wrote: >> I can't explain why it suddenly did not work anymore, but i readhttp://gist.github.com/365816 >> and the only thing i needed to do to make it work was adding the >> following dependencies to my gemfile: >> >> gem "autotest" >> gem "autotest-rails" >> >> The gem autotest-rails was already installed on my system. So can't >> explain why, but now it works. >> There, i fixed it :) >> >> On Aug 30, 9:59 am, nathanvda wrote: >> >> >> >>> Since my update to beta.20 i have this weird thing. >>> Normally i develop with autotest on, and when i get an error: i can >>> check the errors, and they are rerun when i save the files. >> >>> If all my tests pass this is still the current behaviour, but if i >>> have failing tests, autotest will keep running those tests. >>> I am afraid i find that kind of annoying :) >> >>> I am not sure what could cause this. >> >>> In my autotest/discover.rb i have the following lines: >> >>> Autotest.add_discovery { "rails" } >>> Autotest.add_discovery { "rspec2" } >> >>> Is there a way to get the old behaviour back? (tests are only rerun >>> when files have changed) > hmmmm.... adding autotest-rails did not fix it for me. Justin - are you experiencing the same problem? Please take a look at the Autotest section in the README on http://github.com/rspec/rspec-rails. That explains what's been working for me. Let me know whether or not it works for you as well. Cheers, David From jko170 at gmail.com Mon Aug 30 11:30:03 2010 From: jko170 at gmail.com (Justin Ko) Date: Mon, 30 Aug 2010 08:30:03 -0700 (PDT) Subject: [rspec-users] rspec2: autotest keeps rerunning failing tests In-Reply-To: <2FC8921D-CDCB-4596-903A-FE98A76E4EB7@gmail.com> References: <6695fcfe-dbd1-47d0-9938-f227f0b16125@q22g2000yqm.googlegroups.com> <71e7f167-69c1-47c8-b396-7b86d27ffea4@t20g2000yqa.googlegroups.com> <85022101-9fbc-40bc-ab34-6ade946aad7f@q22g2000yqm.googlegroups.com> <2FC8921D-CDCB-4596-903A-FE98A76E4EB7@gmail.com> Message-ID: <8600c593-eaae-438e-b3e0-6655fea2a046@i15g2000yqe.googlegroups.com> Following the instructions in the README, I still have this problem. Downgrading to RSpec beta 19 fixes it. On Aug 30, 11:08?am, David Chelimsky wrote: > On Aug 30, 2010, at 9:56 AM, Justin Ko wrote: > > > > > > > On Aug 30, 8:00 am, nathanvda wrote: > >> I can't explain why it suddenly did not work anymore, but i readhttp://gist.github.com/365816 > >> and the only thing i needed to do to make it work was adding the > >> following dependencies to my gemfile: > > >> gem "autotest" > >> gem "autotest-rails" > > >> The gem autotest-rails was already installed on my system. So can't > >> explain why, but now it works. > >> There, i fixed it :) > > >> On Aug 30, 9:59 am, nathanvda wrote: > > >>> Since my update to beta.20 i have this weird thing. > >>> Normally i develop with autotest on, and when i get an error: i can > >>> check the errors, and they are rerun when i save the files. > > >>> If all my tests pass this is still the current behaviour, but if i > >>> have failing tests, autotest will keep running those tests. > >>> I am afraid i find that kind of annoying :) > > >>> I am not sure what could cause this. > > >>> In my autotest/discover.rb i have the following lines: > > >>> Autotest.add_discovery { "rails" } > >>> Autotest.add_discovery { "rspec2" } > > >>> Is there a way to get the old behaviour back? (tests are only rerun > >>> when files have changed) > > hmmmm.... adding autotest-rails did not fix it for me. > > Justin - are you experiencing the same problem? > > Please take a look at the Autotest section in the README onhttp://github.com/rspec/rspec-rails. That explains what's been working for me. Let me know whether or not it works for you as well. > > Cheers, > David > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users From jko170 at gmail.com Mon Aug 30 11:30:47 2010 From: jko170 at gmail.com (Justin Ko) Date: Mon, 30 Aug 2010 08:30:47 -0700 (PDT) Subject: [rspec-users] rspec2: autotest keeps rerunning failing tests In-Reply-To: <2FC8921D-CDCB-4596-903A-FE98A76E4EB7@gmail.com> References: <6695fcfe-dbd1-47d0-9938-f227f0b16125@q22g2000yqm.googlegroups.com> <71e7f167-69c1-47c8-b396-7b86d27ffea4@t20g2000yqa.googlegroups.com> <85022101-9fbc-40bc-ab34-6ade946aad7f@q22g2000yqm.googlegroups.com> <2FC8921D-CDCB-4596-903A-FE98A76E4EB7@gmail.com> Message-ID: <139fd6e2-aa59-46f9-a133-62dae1aa6574@l20g2000yqm.googlegroups.com> On Aug 30, 11:08?am, David Chelimsky wrote: > On Aug 30, 2010, at 9:56 AM, Justin Ko wrote: > > > > > > > On Aug 30, 8:00 am, nathanvda wrote: > >> I can't explain why it suddenly did not work anymore, but i readhttp://gist.github.com/365816 > >> and the only thing i needed to do to make it work was adding the > >> following dependencies to my gemfile: > > >> gem "autotest" > >> gem "autotest-rails" > > >> The gem autotest-rails was already installed on my system. So can't > >> explain why, but now it works. > >> There, i fixed it :) > > >> On Aug 30, 9:59 am, nathanvda wrote: > > >>> Since my update to beta.20 i have this weird thing. > >>> Normally i develop with autotest on, and when i get an error: i can > >>> check the errors, and they are rerun when i save the files. > > >>> If all my tests pass this is still the current behaviour, but if i > >>> have failing tests, autotest will keep running those tests. > >>> I am afraid i find that kind of annoying :) > > >>> I am not sure what could cause this. > > >>> In my autotest/discover.rb i have the following lines: > > >>> Autotest.add_discovery { "rails" } > >>> Autotest.add_discovery { "rspec2" } > > >>> Is there a way to get the old behaviour back? (tests are only rerun > >>> when files have changed) > > hmmmm.... adding autotest-rails did not fix it for me. > > Justin - are you experiencing the same problem? > > Please take a look at the Autotest section in the README onhttp://github.com/rspec/rspec-rails. That explains what's been working for me. Let me know whether or not it works for you as well. > > Cheers, > David > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users Woops, sorry about not posting at the bottom. From brennon at brennonbortz.com Mon Aug 30 11:59:50 2010 From: brennon at brennonbortz.com (Brennon Bortz) Date: Mon, 30 Aug 2010 16:59:50 +0100 Subject: [rspec-users] Factories vs. stubs/mocks Message-ID: <7BE1FA57-FC86-4508-89BC-BDBFB4409C53@brennonbortz.com> I am, as usual, assigning an instance variable in a controller's index action to find all instances of a model in the database. I want to write a spec that checks that this variable is assigned correctly. I can do: it "should provide a collection of widgets in @widgets" do widget = Widget.create("title" => "my widget") get :index assigns[:widgets].should include(widget) end or: it "should provide a collection of widgets in @widgets" do widget = Factory.create(:widget) get :index assigns[:widgets].should include(widget) end Is there a better way to do this with a mock model, though? Thanks, Brennon Bortz Software Researcher Dundalk Institute of Technology brennon.bortz at casala.ie Ph.D. Researcher & Composer - Sonic Arts Research Centre Queen's University, Belfast brennon at brennonbortz.com / bbortz01 at qub.ac.uk -------------- next part -------------- An HTML attachment was scrubbed... URL: From jko170 at gmail.com Mon Aug 30 12:17:11 2010 From: jko170 at gmail.com (Justin Ko) Date: Mon, 30 Aug 2010 09:17:11 -0700 (PDT) Subject: [rspec-users] Factories vs. stubs/mocks In-Reply-To: <7BE1FA57-FC86-4508-89BC-BDBFB4409C53@brennonbortz.com> References: <7BE1FA57-FC86-4508-89BC-BDBFB4409C53@brennonbortz.com> Message-ID: <254b982d-3e2a-46a8-bdfe-f0512aa8080e@f42g2000yqn.googlegroups.com> On Aug 30, 11:59?am, Brennon Bortz wrote: > I am, as usual, assigning an instance variable in a controller's index action to find all instances of a model in the database. ?I want to write a spec that checks that this variable is assigned correctly. ?I can do: > > it "should provide a collection of widgets in @widgets" do > ? ? ? widget = Widget.create("title" => "my widget") > ? ? ? get :index > ? ? ? assigns[:widgets].should include(widget) > end > > or: > > it "should provide a collection of widgets in @widgets" do > ? ? ? widget = Factory.create(:widget) > ? ? ? get :index > ? ? ? assigns[:widgets].should include(widget) > end > > Is there a better way to do this with a mock model, though? > > Thanks, > > Brennon Bortz > Software Researcher > Dundalk Institute of Technology > brennon.bo... at casala.ie > Ph.D. Researcher & Composer - Sonic Arts Research Centre > Queen's University, Belfast > bren... at brennonbortz.com / bbort... at qub.ac.uk > > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users Currently, what you're doing is checking that the Widget model returns the correct widgets. If you want to isolate your controller spec from the model, you must stub or mock the model method call in the action. Example: it "..." do widget = mock_model(Widget) Widget.should_receive(:all).and_return([widget]) get :index assigns[:widgets].should include(widget) end To check that Widget.all does indeed return the correct widgets, I would spec that behaviour in the Widget model spec. Hope that helps. From brennon at brennonbortz.com Mon Aug 30 12:54:29 2010 From: brennon at brennonbortz.com (Brennon Bortz) Date: Mon, 30 Aug 2010 17:54:29 +0100 Subject: [rspec-users] Factories vs. stubs/mocks In-Reply-To: <254b982d-3e2a-46a8-bdfe-f0512aa8080e@f42g2000yqn.googlegroups.com> References: <7BE1FA57-FC86-4508-89BC-BDBFB4409C53@brennonbortz.com> <254b982d-3e2a-46a8-bdfe-f0512aa8080e@f42g2000yqn.googlegroups.com> Message-ID: <0594856A-5DC7-43B1-B9EA-456135FCABB5@brennonbortz.com> On 30 Aug 2010, at 17:17, Justin Ko wrote: > > > On Aug 30, 11:59 am, Brennon Bortz wrote: >> I am, as usual, assigning an instance variable in a controller's index action to find all instances of a model in the database. I want to write a spec that checks that this variable is assigned correctly. I can do: >> >> it "should provide a collection of widgets in @widgets" do >> widget = Widget.create("title" => "my widget") >> get :index >> assigns[:widgets].should include(widget) >> end >> >> or: >> >> it "should provide a collection of widgets in @widgets" do >> widget = Factory.create(:widget) >> get :index >> assigns[:widgets].should include(widget) >> end >> >> Is there a better way to do this with a mock model, though? >> >> Thanks, >> >> Brennon Bortz >> Software Researcher >> Dundalk Institute of Technology >> brennon.bo... at casala.ie >> Ph.D. Researcher & Composer - Sonic Arts Research Centre >> Queen's University, Belfast >> bren... at brennonbortz.com / bbort... at qub.ac.uk >> >> _______________________________________________ >> rspec-users mailing list >> rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users > > Currently, what you're doing is checking that the Widget model returns > the correct widgets. If you want to isolate your controller spec from > the model, you must stub or mock the model method call in the action. > Example: > > it "..." do > widget = mock_model(Widget) > Widget.should_receive(:all).and_return([widget]) > get :index > assigns[:widgets].should include(widget) > end > > To check that Widget.all does indeed return the correct widgets, I > would spec that behaviour in the Widget model spec. > > Hope that helps. Hrm...that's exactly what I'd started with, and I was getting the following error: Failures: 1) WidgetsController GET 'index' should provide a collection of widgets in @widgets Failure/Error: assigns[:widgets].should include(widget) expected [] to include # Stupidly, I had defined my controller method as: def index @widgets = Widget.find(:all) end Changed that assignment to Widget.all...problem solved. From jko170 at gmail.com Mon Aug 30 13:07:16 2010 From: jko170 at gmail.com (Justin Ko) Date: Mon, 30 Aug 2010 10:07:16 -0700 (PDT) Subject: [rspec-users] Factories vs. stubs/mocks In-Reply-To: <0594856A-5DC7-43B1-B9EA-456135FCABB5@brennonbortz.com> References: <7BE1FA57-FC86-4508-89BC-BDBFB4409C53@brennonbortz.com> <254b982d-3e2a-46a8-bdfe-f0512aa8080e@f42g2000yqn.googlegroups.com> <0594856A-5DC7-43B1-B9EA-456135FCABB5@brennonbortz.com> Message-ID: On Aug 30, 12:54?pm, Brennon Bortz wrote: > On 30 Aug 2010, at 17:17, Justin Ko wrote: > > > > > > > > > On Aug 30, 11:59 am, Brennon Bortz wrote: > >> I am, as usual, assigning an instance variable in a controller's index action to find all instances of a model in the database. ?I want to write a spec that checks that this variable is assigned correctly. ?I can do: > > >> it "should provide a collection of widgets in @widgets" do > >> ? ? ? widget = Widget.create("title" => "my widget") > >> ? ? ? get :index > >> ? ? ? assigns[:widgets].should include(widget) > >> end > > >> or: > > >> it "should provide a collection of widgets in @widgets" do > >> ? ? ? widget = Factory.create(:widget) > >> ? ? ? get :index > >> ? ? ? assigns[:widgets].should include(widget) > >> end > > >> Is there a better way to do this with a mock model, though? > > >> Thanks, > > >> Brennon Bortz > >> Software Researcher > >> Dundalk Institute of Technology > >> brennon.bo... at casala.ie > >> Ph.D. Researcher & Composer - Sonic Arts Research Centre > >> Queen's University, Belfast > >> bren... at brennonbortz.com / bbort... at qub.ac.uk > > >> _______________________________________________ > >> rspec-users mailing list > >> rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users > > > Currently, what you're doing is checking that the Widget model returns > > the correct widgets. If you want to isolate your controller spec from > > the model, you must stub or mock the model method call in the action. > > Example: > > > it "..." do > > ?widget = mock_model(Widget) > > ?Widget.should_receive(:all).and_return([widget]) > > ?get :index > > ?assigns[:widgets].should include(widget) > > end > > > To check that Widget.all does indeed return the correct widgets, I > > would spec that behaviour in the Widget model spec. > > > Hope that helps. > > Hrm...that's exactly what I'd started with, and I was getting the following error: > > Failures: > ? 1) WidgetsController GET 'index' should provide a collection of widgets in @widgets > ? ? ?Failure/Error: assigns[:widgets].should include(widget) > ? ? ?expected [] to include # > > Stupidly, I had defined my controller method as: > > def index > ? @widgets = Widget.find(:all) > end > > Changed that assignment to Widget.all...problem solved. > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users To mock a method that receives an argument, you can use the "with" method. Example: Widget.should_receive(:find).with(:all).and_return([widget]) Glad you got things fixed :) From Rob at AgileConsultingLLC.com Mon Aug 30 13:09:25 2010 From: Rob at AgileConsultingLLC.com (Rob Biedenharn) Date: Mon, 30 Aug 2010 13:09:25 -0400 Subject: [rspec-users] Factories vs. stubs/mocks In-Reply-To: <0594856A-5DC7-43B1-B9EA-456135FCABB5@brennonbortz.com> References: <7BE1FA57-FC86-4508-89BC-BDBFB4409C53@brennonbortz.com> <254b982d-3e2a-46a8-bdfe-f0512aa8080e@f42g2000yqn.googlegroups.com> <0594856A-5DC7-43B1-B9EA-456135FCABB5@brennonbortz.com> Message-ID: On Aug 30, 2010, at 12:54 PM, Brennon Bortz wrote: > On 30 Aug 2010, at 17:17, Justin Ko wrote: >> On Aug 30, 11:59 am, Brennon Bortz wrote: >>> I am, as usual, assigning an instance variable in a controller's >>> index action to find all instances of a model in the database. I >>> want to write a spec that checks that this variable is assigned >>> correctly. I can do: >>> >>> it "should provide a collection of widgets in @widgets" do >>> widget = Widget.create("title" => "my widget") >>> get :index >>> assigns[:widgets].should include(widget) >>> end >>> >>> or: >>> >>> it "should provide a collection of widgets in @widgets" do >>> widget = Factory.create(:widget) >>> get :index >>> assigns[:widgets].should include(widget) >>> end >>> >>> Is there a better way to do this with a mock model, though? >>> >>> Thanks, >>> >>> Brennon Bortz >>> Software Researcher >>> Dundalk Institute of Technology >>> brennon.bo... at casala.ie >>> Ph.D. Researcher & Composer - Sonic Arts Research Centre >>> Queen's University, Belfast >>> bren... at brennonbortz.com / bbort... at qub.ac.uk >>> >>> _______________________________________________ >>> rspec-users mailing list >>> rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users >> >> Currently, what you're doing is checking that the Widget model >> returns >> the correct widgets. If you want to isolate your controller spec from >> the model, you must stub or mock the model method call in the action. >> Example: >> >> it "..." do >> widget = mock_model(Widget) >> Widget.should_receive(:all).and_return([widget]) >> get :index >> assigns[:widgets].should include(widget) >> end >> >> To check that Widget.all does indeed return the correct widgets, I >> would spec that behaviour in the Widget model spec. >> >> Hope that helps. > > Hrm...that's exactly what I'd started with, and I was getting the > following error: > > Failures: > 1) WidgetsController GET 'index' should provide a collection of > widgets in @widgets > Failure/Error: assigns[:widgets].should include(widget) > expected [] to include # > > Stupidly, I had defined my controller method as: > > def index > @widgets = Widget.find(:all) > end > > Changed that assignment to Widget.all...problem solved. And THAT is the problem with using mocks (or stubs) for this. You run the very real risk of specifying the implementation details in the structure of the spec/test. There is a problem when you've limited the refactoring that can be done without altering the spec/test. Since Widget.find(:all) and Widget.all should always have the same result, the mere presence of the mock has cut off one possible refactoring. (The one that I distaste most limits changing .find(params[:id]) to .find_by_id(params[:id]) by mocking/stubbing the call to find.) Think about what really needs to be specified and be careful to mock/ stub as little as possible and to do so in a way that will limit opportunities to refactor the least. -Rob Rob Biedenharn Rob at AgileConsultingLLC.com http://AgileConsultingLLC.com/ rab at GaslightSoftware.com http://GaslightSoftware.com/ From jko170 at gmail.com Mon Aug 30 13:32:11 2010 From: jko170 at gmail.com (Justin Ko) Date: Mon, 30 Aug 2010 10:32:11 -0700 (PDT) Subject: [rspec-users] Factories vs. stubs/mocks In-Reply-To: References: <7BE1FA57-FC86-4508-89BC-BDBFB4409C53@brennonbortz.com> <254b982d-3e2a-46a8-bdfe-f0512aa8080e@f42g2000yqn.googlegroups.com> <0594856A-5DC7-43B1-B9EA-456135FCABB5@brennonbortz.com> Message-ID: <8657e851-91a1-4d5a-9687-2bfb762cf113@q22g2000yqm.googlegroups.com> On Aug 30, 1:09?pm, Rob Biedenharn wrote: > On Aug 30, 2010, at 12:54 PM, Brennon Bortz wrote: > > > > > > > On 30 Aug 2010, at 17:17, Justin Ko wrote: > >> On Aug 30, 11:59 am, Brennon Bortz wrote: > >>> I am, as usual, assigning an instance variable in a controller's ? > >>> index action to find all instances of a model in the database. ?I ? > >>> want to write a spec that checks that this variable is assigned ? > >>> correctly. ?I can do: > > >>> it "should provide a collection of widgets in @widgets" do > >>> ? ? ?widget = Widget.create("title" => "my widget") > >>> ? ? ?get :index > >>> ? ? ?assigns[:widgets].should include(widget) > >>> end > > >>> or: > > >>> it "should provide a collection of widgets in @widgets" do > >>> ? ? ?widget = Factory.create(:widget) > >>> ? ? ?get :index > >>> ? ? ?assigns[:widgets].should include(widget) > >>> end > > >>> Is there a better way to do this with a mock model, though? > > >>> Thanks, > > >>> Brennon Bortz > >>> Software Researcher > >>> Dundalk Institute of Technology > >>> brennon.bo... at casala.ie > >>> Ph.D. Researcher & Composer - Sonic Arts Research Centre > >>> Queen's University, Belfast > >>> bren... at brennonbortz.com / bbort... at qub.ac.uk > > >>> _______________________________________________ > >>> rspec-users mailing list > >>> rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users > > >> Currently, what you're doing is checking that the Widget model ? > >> returns > >> the correct widgets. If you want to isolate your controller spec from > >> the model, you must stub or mock the model method call in the action. > >> Example: > > >> it "..." do > >> widget = mock_model(Widget) > >> Widget.should_receive(:all).and_return([widget]) > >> get :index > >> assigns[:widgets].should include(widget) > >> end > > >> To check that Widget.all does indeed return the correct widgets, I > >> would spec that behaviour in the Widget model spec. > > >> Hope that helps. > > > Hrm...that's exactly what I'd started with, and I was getting the ? > > following error: > > > Failures: > > ?1) WidgetsController GET 'index' should provide a collection of ? > > widgets in @widgets > > ? ? Failure/Error: assigns[:widgets].should include(widget) > > ? ? expected [] to include # > > > Stupidly, I had defined my controller method as: > > > def index > > ?@widgets = Widget.find(:all) > > end > > > Changed that assignment to Widget.all...problem solved. > > And THAT is the problem with using mocks (or stubs) for this. ?You run ? > the very real risk of specifying the implementation details in the ? > structure of the spec/test. ?There is a problem when you've limited ? > the refactoring that can be done without altering the spec/test. Since ? > Widget.find(:all) and Widget.all should always have the same result, ? > the mere presence of the mock has cut off one possible refactoring. ? > (The one that I distaste most limits changing .find(params[:id]) ? > to .find_by_id(params[:id]) by mocking/stubbing the call to find.) > > Think about what really needs to be specified and be careful to mock/ > stub as little as possible and to do so in a way that will limit ? > opportunities to refactor the least. > > -Rob > > Rob Biedenharn ? ? ? ? ? > R... at AgileConsultingLLC.com ?http://AgileConsultingLLC.com/ > r... at GaslightSoftware.com ? ? ? ? ? ?http://GaslightSoftware.com/ > > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users The method you suggested does benefit refactoring. However, by not stubbing or mocking, your controller is no longer in isolation. Which means if Widget.all breaks, the model AND controller spec will fail. The are pros and cons to both ways. But what has pushed me to the isolation side is that without mocking/stubbing, you must create a record in the database (via fixtures or factories) and it is much slower. From jko170 at gmail.com Mon Aug 30 14:24:57 2010 From: jko170 at gmail.com (Justin Ko) Date: Mon, 30 Aug 2010 11:24:57 -0700 (PDT) Subject: [rspec-users] Factories vs. stubs/mocks In-Reply-To: <8657e851-91a1-4d5a-9687-2bfb762cf113@q22g2000yqm.googlegroups.com> References: <7BE1FA57-FC86-4508-89BC-BDBFB4409C53@brennonbortz.com> <254b982d-3e2a-46a8-bdfe-f0512aa8080e@f42g2000yqn.googlegroups.com> <0594856A-5DC7-43B1-B9EA-456135FCABB5@brennonbortz.com> <8657e851-91a1-4d5a-9687-2bfb762cf113@q22g2000yqm.googlegroups.com> Message-ID: On Aug 30, 1:32?pm, Justin Ko wrote: > On Aug 30, 1:09?pm, Rob Biedenharn > wrote: > > > > > > > On Aug 30, 2010, at 12:54 PM, Brennon Bortz wrote: > > > > On 30 Aug 2010, at 17:17, Justin Ko wrote: > > >> On Aug 30, 11:59 am, Brennon Bortz wrote: > > >>> I am, as usual, assigning an instance variable in a controller's ? > > >>> index action to find all instances of a model in the database. ?I ? > > >>> want to write a spec that checks that this variable is assigned ? > > >>> correctly. ?I can do: > > > >>> it "should provide a collection of widgets in @widgets" do > > >>> ? ? ?widget = Widget.create("title" => "my widget") > > >>> ? ? ?get :index > > >>> ? ? ?assigns[:widgets].should include(widget) > > >>> end > > > >>> or: > > > >>> it "should provide a collection of widgets in @widgets" do > > >>> ? ? ?widget = Factory.create(:widget) > > >>> ? ? ?get :index > > >>> ? ? ?assigns[:widgets].should include(widget) > > >>> end > > > >>> Is there a better way to do this with a mock model, though? > > > >>> Thanks, > > > >>> Brennon Bortz > > >>> Software Researcher > > >>> Dundalk Institute of Technology > > >>> brennon.bo... at casala.ie > > >>> Ph.D. Researcher & Composer - Sonic Arts Research Centre > > >>> Queen's University, Belfast > > >>> bren... at brennonbortz.com / bbort... at qub.ac.uk > > > >>> _______________________________________________ > > >>> rspec-users mailing list > > >>> rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users > > > >> Currently, what you're doing is checking that the Widget model ? > > >> returns > > >> the correct widgets. If you want to isolate your controller spec from > > >> the model, you must stub or mock the model method call in the action. > > >> Example: > > > >> it "..." do > > >> widget = mock_model(Widget) > > >> Widget.should_receive(:all).and_return([widget]) > > >> get :index > > >> assigns[:widgets].should include(widget) > > >> end > > > >> To check that Widget.all does indeed return the correct widgets, I > > >> would spec that behaviour in the Widget model spec. > > > >> Hope that helps. > > > > Hrm...that's exactly what I'd started with, and I was getting the ? > > > following error: > > > > Failures: > > > ?1) WidgetsController GET 'index' should provide a collection of ? > > > widgets in @widgets > > > ? ? Failure/Error: assigns[:widgets].should include(widget) > > > ? ? expected [] to include # > > > > Stupidly, I had defined my controller method as: > > > > def index > > > ?@widgets = Widget.find(:all) > > > end > > > > Changed that assignment to Widget.all...problem solved. > > > And THAT is the problem with using mocks (or stubs) for this. ?You run ? > > the very real risk of specifying the implementation details in the ? > > structure of the spec/test. ?There is a problem when you've limited ? > > the refactoring that can be done without altering the spec/test. Since ? > > Widget.find(:all) and Widget.all should always have the same result, ? > > the mere presence of the mock has cut off one possible refactoring. ? > > (The one that I distaste most limits changing .find(params[:id]) ? > > to .find_by_id(params[:id]) by mocking/stubbing the call to find.) > > > Think about what really needs to be specified and be careful to mock/ > > stub as little as possible and to do so in a way that will limit ? > > opportunities to refactor the least. > > > -Rob > > > Rob Biedenharn ? ? ? ? ? > > R... at AgileConsultingLLC.com ?http://AgileConsultingLLC.com/ > > r... at GaslightSoftware.com ? ? ? ? ? ?http://GaslightSoftware.com/ > > > _______________________________________________ > > rspec-users mailing list > > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users > > The method you suggested does benefit refactoring. However, by not > stubbing or mocking, your controller is no longer in isolation. Which > means if Widget.all breaks, the model AND controller spec will fail. > > The are pros and cons to both ways. But what has pushed me to the > isolation side is that without mocking/stubbing, you must create a > record in the database (via fixtures or factories) and it is much > slower. > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users Just remembered another reason why I chose isolation. Sometimes, the setup to NOT isolate can be a real pain. a.k.a creating factories and relationships. But, let's say you've something like this in your controller: User.where(:email => 'test at blah.com').includes(:widgets).order('users.email ASC').limit(3) Simply stubbing or mocking that out would not spec the SQL very well. So what I usually do is extract it to the model: User.widgets_by_email('test at blah.com') # in model def self.widgets_by_email(email) where(:email => email).includes(:widgets).order('users.email ASC').limit(3) end After doing that, I feel comfortable mocking out "User.widgets_by_email" in the controller, because all I care about is if its called or not. And of course, since the method has been moved to the model, you can unit spec the hell out of it :) From krivich.ekaterina at gmail.com Mon Aug 30 10:36:13 2010 From: krivich.ekaterina at gmail.com (sleepwalker) Date: Mon, 30 Aug 2010 07:36:13 -0700 (PDT) Subject: [rspec-users] undefined method `route_for' for # Hello, all, I have this error with my rspec - controller - test, and yes, I do found the thread with the same error here, but it isn't helped me, think it's not my case. i have rails -v = Rails 3.0.0.rc, rspec -v = 2.0.0.beta.18 (hope they should match each other). my test is here: spec/controllers/posts_controller_spec.rb and i ran it with command: rspec spec/controllers/posts_controller_spec.rb. after all, test is: require 'spec_helper' describe PostsController do render_views describe "route generation" do it "should be successful" do @post = Post.new(:title => 'blalbla', :name => 'adfsdfsdf') @post.save route_for(:controller => "posts", :action => "show", :id => @post.id, :method => 'GET').should == "/posts/show" + @post.id.to_s end end end I have Post model and it works just fine (rspec tested fine as well). And the route is (from rake routes): GET /posts/:id(.:format) {:controller=>"posts", :action=>"show"} Can anybody tell me, where the things going wrong for a such answer (undefined method...) Thanks! From allan.cochrane at gmail.com Mon Aug 30 11:29:25 2010 From: allan.cochrane at gmail.com (Allan) Date: Mon, 30 Aug 2010 08:29:25 -0700 (PDT) Subject: [rspec-users] rspec2: autotest keeps rerunning failing tests In-Reply-To: <2FC8921D-CDCB-4596-903A-FE98A76E4EB7@gmail.com> References: <6695fcfe-dbd1-47d0-9938-f227f0b16125@q22g2000yqm.googlegroups.com> <71e7f167-69c1-47c8-b396-7b86d27ffea4@t20g2000yqa.googlegroups.com> <85022101-9fbc-40bc-ab34-6ade946aad7f@q22g2000yqm.googlegroups.com> <2FC8921D-CDCB-4596-903A-FE98A76E4EB7@gmail.com> Message-ID: <5b785ae0-c1c3-4a09-ac43-bdfa3b8e75bb@x25g2000yqj.googlegroups.com> Hi, I tried many variations of gems in Gemfile, modifying options in autotest/discover.rb, running with and without bundle exec but in the end only backing off to 2.0.0.beta.19 stopped failing tests being immediately re-run. Allan From allan.cochrane at gmail.com Mon Aug 30 11:45:07 2010 From: allan.cochrane at gmail.com (Allan) Date: Mon, 30 Aug 2010 08:45:07 -0700 (PDT) Subject: [rspec-users] rspec2: autotest keeps rerunning failing tests In-Reply-To: <8600c593-eaae-438e-b3e0-6655fea2a046@i15g2000yqe.googlegroups.com> References: <6695fcfe-dbd1-47d0-9938-f227f0b16125@q22g2000yqm.googlegroups.com> <71e7f167-69c1-47c8-b396-7b86d27ffea4@t20g2000yqa.googlegroups.com> <85022101-9fbc-40bc-ab34-6ade946aad7f@q22g2000yqm.googlegroups.com> <2FC8921D-CDCB-4596-903A-FE98A76E4EB7@gmail.com> <8600c593-eaae-438e-b3e0-6655fea2a046@i15g2000yqe.googlegroups.com> Message-ID: Same here! Allan On Aug 30, 10:30?am, Justin Ko wrote: > Following the instructions in the README, I still have this problem. > Downgrading to RSpec beta 19 fixes it. > > On Aug 30, 11:08?am, David Chelimsky wrote: > > > > > > > > > On Aug 30, 2010, at 9:56 AM, Justin Ko wrote: > > > > On Aug 30, 8:00 am, nathanvda wrote: > > >> I can't explain why it suddenly did not work anymore, but i readhttp://gist.github.com/365816 > > >> and the only thing i needed to do to make it work was adding the > > >> following dependencies to my gemfile: > > > >> gem "autotest" > > >> gem "autotest-rails" > > > >> The gem autotest-rails was already installed on my system. So can't > > >> explain why, but now it works. > > >> There, i fixed it :) > > > >> On Aug 30, 9:59 am, nathanvda wrote: > > > >>> Since my update to beta.20 i have this weird thing. > > >>> Normally i develop with autotest on, and when i get an error: i can > > >>> check the errors, and they are rerun when i save the files. > > > >>> If all my tests pass this is still the current behaviour, but if i > > >>> have failing tests, autotest will keep running those tests. > > >>> I am afraid i find that kind of annoying :) > > > >>> I am not sure what could cause this. > > > >>> In my autotest/discover.rb i have the following lines: > > > >>> Autotest.add_discovery { "rails" } > > >>> Autotest.add_discovery { "rspec2" } > > > >>> Is there a way to get the old behaviour back? (tests are only rerun > > >>> when files have changed) > > > hmmmm.... adding autotest-rails did not fix it for me. > > > Justin - are you experiencing the same problem? > > > Please take a look at the Autotest section in the README onhttp://github.com/rspec/rspec-rails. That explains what's been working for me. Let me know whether or not it works for you as well. > > > Cheers, > > David > > _______________________________________________ > > rspec-users mailing list > > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users > > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users From jko170 at gmail.com Mon Aug 30 12:17:11 2010 From: jko170 at gmail.com (Justin Ko) Date: Mon, 30 Aug 2010 09:17:11 -0700 (PDT) Subject: [rspec-users] Factories vs. stubs/mocks In-Reply-To: <7BE1FA57-FC86-4508-89BC-BDBFB4409C53@brennonbortz.com> References: <7BE1FA57-FC86-4508-89BC-BDBFB4409C53@brennonbortz.com> Message-ID: <254b982d-3e2a-46a8-bdfe-f0512aa8080e@f42g2000yqn.googlegroups.com> On Aug 30, 11:59?am, Brennon Bortz wrote: > I am, as usual, assigning an instance variable in a controller's index action to find all instances of a model in the database. ?I want to write a spec that checks that this variable is assigned correctly. ?I can do: > > it "should provide a collection of widgets in @widgets" do > ? ? ? widget = Widget.create("title" => "my widget") > ? ? ? get :index > ? ? ? assigns[:widgets].should include(widget) > end > > or: > > it "should provide a collection of widgets in @widgets" do > ? ? ? widget = Factory.create(:widget) > ? ? ? get :index > ? ? ? assigns[:widgets].should include(widget) > end > > Is there a better way to do this with a mock model, though? > > Thanks, > > Brennon Bortz > Software Researcher > Dundalk Institute of Technology > brennon.bo... at casala.ie > Ph.D. Researcher & Composer - Sonic Arts Research Centre > Queen's University, Belfast > bren... at brennonbortz.com / bbort... at qub.ac.uk > > _______________________________________________ > rspec-users mailing list > rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users Currently, what you're doing is checking that the Widget model returns the correct widgets. If you want to isolate your controller spec from the model, you must stub or mock the model method call in the action. Example: it "..." do widget = mock_model(Widget) Widget.should_receive(:all).and_return([widget]) get :index assigns[:widgets].should include(widget) end To check that Widget.all does indeed return the correct widgets, I would spec that behaviour in the Widget model spec. Hope that helps. From dchelimsky at gmail.com Mon Aug 30 19:49:58 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 30 Aug 2010 18:49:58 -0500 Subject: [rspec-users] undefined method `route_for' for # References: <4962f15a-2f22-4f06-8234-eacd0f405b08@q22g2000yqm.googlegroups.com> Message-ID: <5B228474-D61B-4E94-86F2-F903B33602D6@gmail.com> On Aug 30, 2010, at 9:36 AM, sleepwalker wrote: > Hello, all, I have this error with my rspec - controller - test, and > yes, I do found the thread with the same error here, but it isn't > helped me, think it's not my case. > > i have rails -v = Rails 3.0.0.rc, rspec -v = 2.0.0.beta.18 (hope they > should match each other). > > my test is here: spec/controllers/posts_controller_spec.rb and i ran > it with command: rspec spec/controllers/posts_controller_spec.rb. > > after all, test is: > > require 'spec_helper' > > describe PostsController do > render_views > describe "route generation" do > > it "should be successful" do > @post = Post.new(:title => 'blalbla', :name => 'adfsdfsdf') > @post.save > route_for(:controller => "posts", :action => "show", :id => > @post.id, :method => 'GET').should == "/posts/show" + @post.id.to_s > end > end > end > > I have Post model and it works just fine (rspec tested fine as well). > And the route is (from rake routes): > GET /posts/:id(.:format) > {:controller=>"posts", :action=>"show"} > > Can anybody tell me, where the things going wrong for a such answer > (undefined method...) Thanks! route_for is gone See the section on Routing specs on http://github.com/rspec/rspec-rails for how to do routing specs. I'll add a note that route_for is gone. Cheers, David From matt at mattwynne.net Tue Aug 31 05:01:07 2010 From: matt at mattwynne.net (Matt Wynne) Date: Tue, 31 Aug 2010 10:01:07 +0100 Subject: [rspec-users] Factories vs. stubs/mocks In-Reply-To: <8657e851-91a1-4d5a-9687-2bfb762cf113@q22g2000yqm.googlegroups.com> References: <7BE1FA57-FC86-4508-89BC-BDBFB4409C53@brennonbortz.com> <254b982d-3e2a-46a8-bdfe-f0512aa8080e@f42g2000yqn.googlegroups.com> <0594856A-5DC7-43B1-B9EA-456135FCABB5@brennonbortz.com> <8657e851-91a1-4d5a-9687-2bfb762cf113@q22g2000yqm.googlegroups.com> Message-ID: On 30 Aug 2010, at 18:32, Justin Ko wrote: > > > On Aug 30, 1:09 pm, Rob Biedenharn > wrote: >> On Aug 30, 2010, at 12:54 PM, Brennon Bortz wrote: >> >> >> >> >> >>> On 30 Aug 2010, at 17:17, Justin Ko wrote: >>>> On Aug 30, 11:59 am, Brennon Bortz wrote: >>>>> I am, as usual, assigning an instance variable in a controller's >>>>> index action to find all instances of a model in the database. I >>>>> want to write a spec that checks that this variable is assigned >>>>> correctly. I can do: >> >>>>> it "should provide a collection of widgets in @widgets" do >>>>> widget = Widget.create("title" => "my widget") >>>>> get :index >>>>> assigns[:widgets].should include(widget) >>>>> end >> >>>>> or: >> >>>>> it "should provide a collection of widgets in @widgets" do >>>>> widget = Factory.create(:widget) >>>>> get :index >>>>> assigns[:widgets].should include(widget) >>>>> end >> >>>>> Is there a better way to do this with a mock model, though? >> >>>>> Thanks, >> >>>>> Brennon Bortz >>>>> Software Researcher >>>>> Dundalk Institute of Technology >>>>> brennon.bo... at casala.ie >>>>> Ph.D. Researcher & Composer - Sonic Arts Research Centre >>>>> Queen's University, Belfast >>>>> bren... at brennonbortz.com / bbort... at qub.ac.uk >> >>>>> _______________________________________________ >>>>> rspec-users mailing list >>>>> rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users >> >>>> Currently, what you're doing is checking that the Widget model >>>> returns >>>> the correct widgets. If you want to isolate your controller spec from >>>> the model, you must stub or mock the model method call in the action. >>>> Example: >> >>>> it "..." do >>>> widget = mock_model(Widget) >>>> Widget.should_receive(:all).and_return([widget]) >>>> get :index >>>> assigns[:widgets].should include(widget) >>>> end >> >>>> To check that Widget.all does indeed return the correct widgets, I >>>> would spec that behaviour in the Widget model spec. >> >>>> Hope that helps. >> >>> Hrm...that's exactly what I'd started with, and I was getting the >>> following error: >> >>> Failures: >>> 1) WidgetsController GET 'index' should provide a collection of >>> widgets in @widgets >>> Failure/Error: assigns[:widgets].should include(widget) >>> expected [] to include # >> >>> Stupidly, I had defined my controller method as: >> >>> def index >>> @widgets = Widget.find(:all) >>> end >> >>> Changed that assignment to Widget.all...problem solved. >> >> And THAT is the problem with using mocks (or stubs) for this. You run >> the very real risk of specifying the implementation details in the >> structure of the spec/test. There is a problem when you've limited >> the refactoring that can be done without altering the spec/test. Since >> Widget.find(:all) and Widget.all should always have the same result, >> the mere presence of the mock has cut off one possible refactoring. >> (The one that I distaste most limits changing .find(params[:id]) >> to .find_by_id(params[:id]) by mocking/stubbing the call to find.) >> >> Think about what really needs to be specified and be careful to mock/ >> stub as little as possible and to do so in a way that will limit >> opportunities to refactor the least. >> >> -Rob >> >> Rob Biedenharn >> R... at AgileConsultingLLC.com http://AgileConsultingLLC.com/ >> r... at GaslightSoftware.com http://GaslightSoftware.com/ >> >> _______________________________________________ >> rspec-users mailing list >> rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users > > The method you suggested does benefit refactoring. However, by not > stubbing or mocking, your controller is no longer in isolation. Which > means if Widget.all breaks, the model AND controller spec will fail. > > The are pros and cons to both ways. But what has pushed me to the > isolation side is that without mocking/stubbing, you must create a > record in the database (via fixtures or factories) and it is much > slower. Personally, I would use this as a driver to create a new method on Widget which did exactly what this controller wants, wrapping the details of the ActiveRecord API. That way, I have a nice, readable controller with fast, isolated, specs; a clear API on my models that makes sense in my domain; and if I want to change from a relational DB to a key-value store, I don't have a dependency on ActiveRecord leaking out of my model all over the place. > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users cheers, Matt http://blog.mattwynne.net +44(0)7974 430184 From dolzenko at gmail.com Tue Aug 31 14:45:43 2010 From: dolzenko at gmail.com (Evgeniy Dolzhenko) Date: Tue, 31 Aug 2010 22:45:43 +0400 Subject: [rspec-users] Global before block for specific spec type Message-ID: So previously it seems it was possible to configure global before block which will get run, say only for controller specs (people even used that I think http://stackoverflow.com/questions/590100/setting-the-http-referer-in-a-global-beforeall-in-rspec/592219#592219 ) Now I wasn't able to find anything like that, and the closest thing I came up with is: RSpec.configure do |config| config.before(:all) do if self.class.metadata[:type] == :view # do my dirty deeds with ViewExampleGroup end end end Is that OK? From dchelimsky at gmail.com Tue Aug 31 14:47:26 2010 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 31 Aug 2010 13:47:26 -0500 Subject: [rspec-users] Global before block for specific spec type In-Reply-To: References: Message-ID: On Aug 31, 2010, at 1:45 PM, Evgeniy Dolzhenko wrote: > So previously it seems it was possible to configure global before block which > will get run, say only for controller specs (people even used that I > think http://stackoverflow.com/questions/590100/setting-the-http-referer-in-a-global-beforeall-in-rspec/592219#592219 > ) > > Now I wasn't able to find anything like that, and the closest thing I > came up with > is: > > RSpec.configure do |config| > config.before(:all) do > if self.class.metadata[:type] == :view > # do my dirty deeds with ViewExampleGroup > end > end > end > > Is that OK? Better to do this: RSpec.configure do |config| config.before(:all, :type => :view) do # do stuff end end