I would be interested to hear any thoughts from the community about the ability to request specific examples from a shared example group as expressed in the rspec-requestable-examples gem. Here''s the post that introduces them: http://mutuallyhuman.com/blog/2012/01/27/rspec-requestable-examples Git repository: https://github.com/mhs/rspec-requestable-examples -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com @zachdennis (twitter)
On Fri, Jan 27, 2012 at 8:56 PM, Zach Dennis <zach.dennis at gmail.com> wrote:> I would be interested to hear any thoughts from the community about > the ability to request specific examples from a shared example group > as expressed in the rspec-requestable-examples gem.I love the service it provides, and the consuming API (i.e. :examples => [...]). It clearly communicates to the spec reader what is going on. As for the setup API, how about "requestable_example" instead of "requestable_it". In fact, I think "selectable" would be a more accurate descriptor than "requestable", so "selectable_examples_for" and "selectable_example" would read better for me. I haven''t looked at the implementation yet, but I wonder if you could implement the same feature using metadata. Something like this, using "selectable" rather than "requestable" (seems better aligned with what it''s doing IMO): shared_examples_for "variable things", :selectable do it "does one thing sometimes", :selectable do # ... end it "does another thing sometimes", :selectable do # ... end it "does one other thing all the time" do # ... end end That way we don''t need a new method name to worry about and my issue with the name "requestable_it" goes away. WDYT?> Here''s the post that introduces them: > http://mutuallyhuman.com/blog/2012/01/27/rspec-requestable-examples > > Git repository: https://github.com/mhs/rspec-requestable-examples > > -- > Zach Dennis > http://www.continuousthinking.com > http://www.mutuallyhuman.com > @zachdennis (twitter) > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users
On Sat, Jan 28, 2012 at 5:56 PM, David Chelimsky <dchelimsky at gmail.com> wrote:> On Fri, Jan 27, 2012 at 8:56 PM, Zach Dennis <zach.dennis at gmail.com> wrote: >> I would be interested to hear any thoughts from the community about >> the ability to request specific examples from a shared example group >> as expressed in the rspec-requestable-examples gem. > > I love the service it provides, and the consuming API (i.e. :examples > => [...]). It clearly communicates to the spec reader what is going > on. > > As for the setup API, how about "requestable_example" instead of > "requestable_it". In fact, I think "selectable" would be a more > accurate descriptor than "requestable", so "selectable_examples_for" > and "selectable_example" would read better for me.I agree with you, "selectable" seems like a better fit, but this may not apply in its entirety given your next suggestion...> > I haven''t looked at the implementation yet, but I wonder if you could > implement the same feature using metadata. Something like this, using > "selectable" rather than "requestable" (seems better aligned with what > it''s doing IMO): > > shared_examples_for "variable things", :selectable do > ?it "does one thing sometimes", :selectable do > ? ?# ... > ?end > > ?it "does another thing sometimes", :selectable do > ? ?# ... > ?end > > ?it "does one other thing all the time" do > ? ?# ... > ?end > end > > That way we don''t need a new method name to worry about and my issue > with the name "requestable_it" goes away. > > WDYT?I like what you''re suggesting here as well. One reason I had went with a new method name for this was to not conflict with RSpec itself, but given your feedback I will investigate what you propose above. Thanks for taking the time to review and to respond, Zach> >> Here''s the post that introduces them: >> http://mutuallyhuman.com/blog/2012/01/27/rspec-requestable-examples >> >> Git repository: https://github.com/mhs/rspec-requestable-examples >> >> -- >> Zach Dennis >> http://www.continuousthinking.com >> http://www.mutuallyhuman.com >> @zachdennis (twitter) >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users-- -- @zachdennis http://www.continuousthinking.com http://www.mutuallyhuman.com
On Jan 27, 2012, at 9:56 PM, Zach Dennis wrote:> I would be interested to hear any thoughts from the community about > the ability to request specific examples from a shared example group > as expressed in the rspec-requestable-examples gem. > > Here''s the post that introduces them: > http://mutuallyhuman.com/blog/2012/01/27/rspec-requestable-examples > > Git repository: https://github.com/mhs/rspec-requestable-examplesI''ve successfully used macros to get similar results, like in the gist below: # macros approach to requestable examples https://gist.github.com/1700352 Curious if you see any big advantages over the macros approach. -lenny> > -- > Zach Dennis > http://www.continuousthinking.com > http://www.mutuallyhuman.com > @zachdennis (twitter) > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users
On Sun, Jan 29, 2012 at 3:04 PM, Lenny Marks <lenny at aps.org> wrote:> > On Jan 27, 2012, at 9:56 PM, Zach Dennis wrote: > >> I would be interested to hear any thoughts from the community about >> the ability to request specific examples from a shared example group >> as expressed in the rspec-requestable-examples gem. >> >> Here''s the post that introduces them: >> http://mutuallyhuman.com/blog/2012/01/27/rspec-requestable-examples >> >> Git repository: https://github.com/mhs/rspec-requestable-examples > > I''ve successfully used macros to get similar results, like in the gist below: > > # macros approach to requestable examples > https://gist.github.com/1700352 > > Curious if you see any big advantages over the macros approach. >Both approaches can get the job done technically speaking. Here were some goals of rspec-requestable-examples: 1. allowing individual examples to be selected from a shared set of examples 2. when a user selects a non-existent example communicate that to them so they can implement the example or fix their typo 3. be consistent and complementary with RSpec''s forms 4. be consistent with RSpec method of delivery (communication) With these goals macros let''s you technically do #1 and #2: * modules allow you to create shared sets of methods which can be shared * when referring to a non-existent method Ruby will yell at you But it fails for #3 and #4: * RSpec has a shared example group form already. Modules are not needed at this level because RSpec provides a higher level concept which provides the utility of sharing examples (it just didn''t have baked in the ability to select individual examples). Plain old Ruby modules breaks away from this form and does not complement what RSpec is doing. * RSpec communicates to the user in terms of nice spec output for passing, failing, and pending examples. It is less work for a user to stub out an example which is not yet implemented as they write their spec and to move on, then to have to see low-level Ruby undefined method errors and have to go stub it out right then and there. I would rather have an unknown example be pending so the user could take care of it at the time they were ready. And even though using "extend ..." and ruby methods are easy to do (and they do technically work) I find it complicates my specs because they exist at a different level of language and communication than all of the other components in my specs. I prefer the language and forms I use to be as consistent as I can make them in my specs. For me, this helps my rhythm of creating software. There is a level of consistency and continuity I want my code to have and in the rspec-requestable-examples approach I try to find that with what RSpec already provides and how it is already being used. I feel like the macro approach attempts to shoehorn in a solution and that''s what I''ve done that in the past, but I think the requestable/selectable examples is better now for reasons above mentioned. In the original blog post it may have sounded like we hit problem A and then in 5 minutes we came up with a solution. When really that''s not the case. I''ve done the macro approach a number of times in the past and never felt comfortable with it, but it worked and we didn''t have a better way. But this time, we finally found a way to make do it a little better (at least in our opinion). -- @zachdennis http://www.continuousthinking.com http://www.mutuallyhuman.com
I forgot to answer your question more directly. I see things in the requestable/selectable approach which I would like to continue to explore and see if it pans out. So far I like the requestable/selectable approach for the reasons I mentioned in the other email. In short term practical use there are no giant reasons why you should avoid using macros. They provide a valuable utility. As mentioned in the other email I think there are benefits (both short and long term) of not using them in favor of an approach that integrates more consistently and at the same communication level as RSpec. Currently, I think the requestable/selectable has the potential to be that (or maybe help lead a discussion and exploration which becomes that). But it''s an experiment that so far has worked a few times. I would hardly say it''s time tested or community tested at this point. And if macros are working well for you and my thinking is persuasive, then so be it, just keep on doing what helps you craft good software. Zach On Mon, Jan 30, 2012 at 11:46 PM, Zach Dennis <zach.dennis at gmail.com> wrote:> On Sun, Jan 29, 2012 at 3:04 PM, Lenny Marks <lenny at aps.org> wrote: >> >> On Jan 27, 2012, at 9:56 PM, Zach Dennis wrote: >> >>> I would be interested to hear any thoughts from the community about >>> the ability to request specific examples from a shared example group >>> as expressed in the rspec-requestable-examples gem. >>> >>> Here''s the post that introduces them: >>> http://mutuallyhuman.com/blog/2012/01/27/rspec-requestable-examples >>> >>> Git repository: https://github.com/mhs/rspec-requestable-examples >> >> I''ve successfully used macros to get similar results, like in the gist below: >> >> # macros approach to requestable examples >> https://gist.github.com/1700352 >> >> Curious if you see any big advantages over the macros approach. >> > > Both approaches can get the job done technically speaking. Here were > some goals of rspec-requestable-examples: > > 1. allowing individual examples to be selected from a shared set of examples > 2. when a user selects a non-existent example communicate that to them > so they can implement the example or fix their typo > 3. be consistent and complementary with RSpec''s forms > 4. be consistent with RSpec method of delivery (communication) > > With these goals macros let''s you technically do #1 and #2: > > * modules allow you to create shared sets of methods which can be shared > * when referring to a non-existent method Ruby will yell at you > > But it fails for #3 and #4: > > * RSpec has a shared example group form already. Modules are not > needed at this level because RSpec provides a higher level concept > which provides the utility of sharing examples (it just didn''t have > baked in the ability to select individual examples). Plain old Ruby > modules breaks away from this form and does not complement what RSpec > is doing. > > * RSpec communicates to the user in terms of nice spec output for > passing, failing, and pending examples. It is less work for a user to > stub out an example which is not yet implemented as they write their > spec and to move on, then to have to see low-level Ruby undefined > method errors and have to go stub it out right then and there. I would > rather have an unknown example be pending so the user could take care > of it at the time they were ready. > > And even though using "extend ..." and ruby methods are easy to do > (and they do technically work) I find it complicates my specs because > they exist at a different level of language and communication than all > of the other components in my specs. I prefer the language and forms I > use to be as consistent as I can make them in my specs. For me, this > helps my rhythm of creating software. > > There is a level of consistency and continuity I want my code to have > and in the rspec-requestable-examples approach I try to find that with > what RSpec already provides and how it is already being used. I feel > like the macro approach attempts to shoehorn in a solution and that''s > what I''ve done that in the past, but I think the > requestable/selectable examples is better now for reasons above > mentioned. > > In the original blog post it may have sounded like we hit problem A > and then in 5 minutes we came up with a solution. When really that''s > not the case. I''ve done the macro approach a number of times in the > past and never felt comfortable with it, but it worked and we didn''t > have a better way. But this time, we finally found a way to make do it > a little better (at least in our opinion). > > -- > @zachdennis > http://www.continuousthinking.com > http://www.mutuallyhuman.com-- -- @zachdennis http://www.continuousthinking.com http://www.mutuallyhuman.com